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PREFACE 



MANUAL OBJECTIVES 

This reference manual provides a description of the instruction set as 
well as a general background on the ELXSI SYSTEM 6400 Architecture. 



INTENDED AUDIENCE 

This manual is intended for users who desire to write low level 
software for the ELXSI. Readers are encouraged to use the higher level 
ELXSI supplied languages whenever possible for the following reasons: 

1. Many of the instructions do not provide data checking for speed 
and performance advantages. The user may be required to provide 
specially emitted code for this purpose. 

2. The instruction set is designed specifically for compilers 
rather than for the writer in assembly language. 

3. The message system instructions have powerful analogues in the 
higher level intrinsics that are more convenient. 



DOCUMENT STRUCTURE 

Chapter 1, "System Overview", provides a general introduction to the 
ELXSI 6400 features and design. 

Chapter 2, "Architecture", characterizes the CPU, memory management, 
and various- internal registers and mechanisms. The chapter provides 
sufficient context for the user who intends to stay within a process 
space . 

Chapter 3, "Data Representations", describes the ELXSI data types. 
Included is a brief discussion on the proposed IEEE Floating Point 
Standard and how it is implemented on the ELXSI. 

Chapter 4, "Instruction Set Composition", describes the format and 
implementation of standard ELXSI primitives. 

Chapter 5, "Data Transfer Instructions", describes those instructions 
that primarily move data. Included are loads and stores, bit field, 
string, and mutual exclusion. 

Chapter 6, "Integer Arithmetic Instructions", describes the integer and 
arithmetic shift instructions. A general discussion on implementing 
multiple precision arithmetic with the "carry" mechanism is included. 
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Chapter 7, "Floating Point Instructions", describes the floating point 
arithmetic instructions. This chapter assumes in-depth familiarity 
with chapters 2 and 3. 

Chapter 8, "ASCII Arithmetic Instructions", covers the ASCII encoded 
decimal arithmetic operations. 

Chapter 9, "Logical Instructions", describes a wide ranging group of 
logical instructions. 

Chapter 10, "Relational Test Instructions", describes those 
instructions that perform a specified action based on the outcome of a 
relational test. 

Chapter 11, "Data Conversion Instructions", describes the group of 
instructions used to convert to different data types. 

Chapter 12, "Flow of Control Instructions", includes simple branching, 
procedure calls, breakpoints and exceptions. 

Chapter 13, "Inter-Process Communications", is a general discussion on 
the message system and process communication structures. 

Chapter 14, "Message System Instructions", describes the instructions 
used for communication between processes. 

Chapter 15, "General Instructions", includes instructions for accessing 
certain internal registers used in the process management, and 
miscellaneous instructions. 

Appendix A, "Alphabetical List of Opcodes", is provided to supplement 
the index for fast look-ups of instruction descriptions. 

Appendix B, "Data Types", illustrates the storage formats for each of 
the ELXSI data types. This may be considered as a quick reference 
summary of much of the information in Chapter 3. 

Appendix C, "Generalized Addressing Instruction Formats", describes the 
generalized instruction storage format for each generalized addressing 
mode. 

Appendix D, "Non-generalized Addressing Instruction Formats", describes 
the storage formats of the non-generalized instructions. 

Appendix E, "ELXSI Machine Instruction Descriptors", is a glossary of 
the symbol notation used in describing how the instructions work. 
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1 SYSTEM OVERVIEW 

The ELXSI SYSTEM 6400 is designed for applications that require very 
high performance, efficient concurrent processing, and system 
flexibility. The ELXSI solution lies in a highly effective 
multiprocessor utilization through a process oriented and message based 
architecture. The message system allows processes to simply "plug in" 
without concern by the user of machine dependent operations, resulting 
in a system adaptable to a wide range of applications, capable of 
evolving in any dimension the user may find necessary, and having an 
inherently high level of security. 



1.1 PROCESS ORIENTED ENVIRONMENT 

The ELXSI 6400 features a novel architecture to optimize the concurrent 
execution of processes. The problem of concurrent execution is related 
to the management of critical sections and of efficient utilization of 
system resources. Procedure based systems tend to be limited by the 
necessity of synchronous job execution, resulting in the wasteful 
suspension of CPUs in cases where serialized access becomes necessary. 
This problem is compounded with the addition of more CPUs to the point 
where the performance rolloff effectively limits the size of the 
system. 

The ELXSI 6400 is a process based system. User tasks and the operating 
system are hierarchically organized but distributed throughout the 
machine, executing asynchronously. Rather than using privileged modes 
as in a procedure based system, resource management and inter-process 
communication are performed entirely through messages. The program (or 
user) may be split up among processes that communicate with each other 
through a message system, each with its own 32-bit address space. As 
such, a failure in the code of one process cannot destroy other 
processes, providing firewall protection and information hiding 
attributes . 



1.2 THE OPERATING SYSTEM 

The operating system, itself a collection of processes, plugs into the 
message system and allows the utilization of system resources by the 
user. Synchronization and allocation of these resources is 
accomplished through messages, with context associated with a process 
or a set of processes. This is in contrast with a procedure based 
system, where synchronization and resource management are performed via 
shared memory locks handled by privileged procedures. Context in this 
case is associated with procedures, and a process calls different 
procedures to accomplish a task. 
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1.3 INTER-PROCESS COMMUNICATIONS 

The communication structure belonging to a process is a defining 
attribute. This includes the communication paths and the priority of 
the process relative to other processes. Whether a resource such as 
the CPU is given over to a process is determined by the message traffic 
for higher priority processes, if any, relative to the availability of 
the resources. When a higher priority process has completed execution 
of all of its messages, the resource is released for the next higher 
priority process. The effect is better load balancing and system 
utilization. 



1.4 THE VIRTUAL MACHINE 

Processes are the smallest executable entities that may be allocated 
resources. A user may be a process or a collection of processes that 
communicate with each other through the message system. The ELXSI 
appears to a process as a virtual machine having 16 64-bit general 
purpose registers, with other internal registers for control and 
management of process states. The process may have a total of 4 
gigabytes of virtual memory, of which 2 gigabytes are private 
addressable space for the process. The only communication between 
processes is through the message system. 

Procedures may be invoked within the process space through mechanisms 
that are both efficient and simple to implement. 



1.5 THE MESSAGE SYSTEM 

The message system is the means by which processes communicate and is 
highly amenable to the design of modular programs having processes that 
easily connect to each other. The communication mechanism is 
completely transparent to sending processes, allowing process 
substitution or I/O redirection by the operating system. 

Unlike traditional architectures, a message system allows a high degree 
of security between processes through hardware enforced protection. 
Specifically, communication between processes may be only by mutual 
consent, with messages encoded through firmware with the ID of the 
sending process. Furthermore, since memory is not implicitly shared, a 
failure of one process, malevolent or otherwise, cannot affect other 
processes. The high security of this system obviates the need for 
privileged and user modes with the associated special instructions. 
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1.6 THE INSTRUCTION SET 

The ELXSI instruction set is designed specifically for the emission of 
very fast code by a compiler. A complete set of primitives, variable 
length instruction formats, and a wide range of addressing modes 
optimize flexibility and code compaction. Instructions exist for 
operations internal to a process and for operations to communicate 
between processes. The latter, known as message system instructions, 
have functionally equivalent intrinsics in the high level ELXSI 
supplied languages. 

The instruction set supports several data types including Integer, 
Numeric string (ASCII) , String, Logical, Character, and Floating Point. 
The Floating Point is based on the proposed IEEE Standard for Binary 
Floating Point Arithmetic and supports 32-, 64-, and 80-bit floating 
point operands. 



1.7 ELXSI SYSTEM 6400 SPECIFICATIONS 



Table 1-1. ELXSI SYSTEM 6400 Specifications 



GENERAL 



Multiple CPU 
Bus Oriented 
Message Based 



1-10 CPUs, 1-4 IOPs 



SYSTEM BUS (GIGABUS) 



Cycle Time 
Width 

Transfer Rate 
Error Checks 



25 nanoseconds 

64-bit (110 bits total) 

160-213 Megabytes/second (usable data) 

Full internal parity 



CENTRAL PROCESSING UNIT 



Type 

Logic 

Word length 

Cycle time 

Registers 

Cache 



Address space 
Floating point 



Microprogrammed general purpose 

LSI/ECL 

64 bits 

50 nanoseconds 

16 sets of general purpose & internal registers 

16-Kbyte, 2-way set associative, 32-byte blocks 

100 nanosecond access 

16 sets of translation look-aside buffers (TLB) 

4 gigabytes 

IEEE proposed standard, 32-, 64-, 80-bit 
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MEMORY SYSTEM 

Type 

Minimum size 
Maximum size 
Cycle time 

I/O PROCESSOR 

Type 
Logic 

Word Length 
Cycle Time 
I/O Rate 



64-Kbit MOS with error detection/correction 

4 Mbytes 

192 Mbytes 

400 nanoseconds (128-bit read, 64-bit write) 



Microprogrammed digital computer 

LSI/ECL 

64 bits 

50 nanoseconds 

Two 8 Mbyte/ second sub-busses 



SERVICE PROCESSOR 

Type 

PERIPHERALS 



M68000 based with 256 Kbytes memory 



Disk 

Mag Tape 
Printers 



300 and 474 Mbyte SMD drives 
6250/1600 and 1600/800 bpi at 125 ips 
1200 and 1800 lines per minute 



SOFTWARE 

Operating System 

Languages 

DBMS 



EMBOS - ELXSI Message Based Operating System 
Pascal, FORTRAN 77, C, COBOL- 74, BASIC 
Relational model 



ENVIRONMENTAL SPECIFICATIONS (4-processor configuration) 



Power 

Temperature 
Relative Humidity 
Cooling 
Dimensions 
Weight 



208V, 3 phase, 47-63 Hz, 60 amps operating 

(450 amps startup) 

4-27 degrees Centigrade 

40-80% non-condensing 

74,000 BTU/hr. 

59"W, 32"D, 70"H 

2500 lbs. (approximate) 
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2 ARCHITECTURE 

This chapter covers those architectural features and mechanisms that 
are within the user environment of the ELXSI instruction set. Topics 
in all chapters up to Chapter 13, "Inter-Process Communications", 
assume a virtual machine as viewed by a single process. 

Data is 64 bits in length when in registers, and is of variable length 
in byte addressable memory. The ELXSI conventions have data fields 
from left to right, high order to low order, with the most significant 
bit (or byte) as bit zero (or byte zero) . A complete discussion of 
data representations may be found in Chapter 3, "Data Representations". 



2.1 GENERAL PURPOSE REGISTERS 

A process has 16 64-bit general purpose registers (GPRs) . These 
registers are used in support of normal ALU operations and for register 
direct and register indirect addressing. The GPRs in this text are 
referred to as RO through R15. 



2.1.1 Implicit Register Usage 

Certain general purpose registers may be used for parameter passing 
during a procedure CALL and EXIT, during an interrupt, and when using 
the IXIT, BXIT and BREAKPOINT instructions. In these cases, R15 is 
used as a stack pointer or, with the branch through register 
instructions, as a location for the the return address. Additionally, 
addressing modes 8 and 9 implicitly use R15 as a base address register. 

Operations that place a result into two registers (such as MUL.128 and 
double extended floating point) must not use R15 as the register 
containing the low order result, as such operations are illegal. Aside 
from these restrictions, the reader should use caution so as not to 
inadvertently destroy the stack pointer. 

The implicit usage of registers RO through R4 is described in Section 
2.4, "Interrupts and Breakpoints". 



2.2 PROCESS STATUS WORD 

The Process Status Word is a 64-bit internal register maintained for 
each process. Its purpose is to record or modify certain events 
occurring within a process, such as arithmetic exceptions or the 
determination of rounding modes. Paired exception bits are provided to 
allow the user the option of entering special routines on the event of 
unusual occurrences. 

The PSW may be accessed and modified by the instructions READ. STAT and 
WRITE. STAT. The bits are numbered through 63, with being the high 
order (leftmost) bit. The table below contains a description of each 
of these bits. 
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Bits 1 through 12 simply record or activate some process states. The 
default values in the table indicate the bit state on process start-up. 

Bits 16 through 63 are paired exception bits. An exception is a 
procedure call through an interrupt, invoked when a system or user 
defined condition occurs during the execution of an instruction. An 
access violation is an example of a system defined condition. A 
relation that is tested by the user through the test and generate 
exception instructions may be defined such that an exception is 
generated when the relation is true. This is a user defined condition. 

The odd numbered bits in the bit pair are the exception occurred bits. 
These bits are unconditionally set on the occurrence of the associated 
exception. For example, an attempted Integer divide by zero will 
always set bit 19. The exception occurred bits are cleared on process 
startup; thereafter, the bits are only cleared explicitly by the user 
through the WRITE. STAT instruction or through the invocation of a 
system supplied exception handler. 
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Table 2-1. Process Status Word (Page 1 of 2) 



| Bit Field 


Description 




i 00- 


■01 


Floating Point Rounding Mode (RMODE) 

00 - Round nearest (RN) - DEFAULT 

01 - Round to zero (RZ) 

10 - Round to plus infinity (RP) 

11 - Round to minus infinity (RM) 


1 02- 


-08 


Reserved 




! 09 




Integer carry bit 

- Carry cleared (for ADD) 

Carry set (for SUB) 

1 - Carry set (for ADD) 

Carry cleared (for SUB) 


- DEFAULT 


! io 




Decimal carry bit 

- Carry cleared (for ADD) 

Carry set (for SUB) 

1 - Carry set (for ADD) 

Carry cleared (for SUB) 


- DEFAULT 


! ii 




Flush Underflows to Zero 

- Use denormalized numbers 

1 - Flush underflows to zero 


- DEFAULT 


! 12 




Single Step Pending 

- No single step pending - 

1 - Single step pending 


DEFAULT 


! 13- 


-15 


Reserved 
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Table 2-1. Process Status Word (Page 2 of 2) 



Bit Pair 


Exception Description ] 


Exception Enable 


Default 


16-17 


Integer Overflow 


i 


1 


18-19 


Integer Divide by Zero 




1 


20-21 


Floating Point Overflow 







22-23 


Floating Point Underflow 







24-25 


Floating Point Divide by Zero 







26-27 


Floating Point Invalid Operation ] 





28-29 


Floating Point Inexact Result 







30-55 


Reserved 







56-57 


Software generated exception 




1 


58-59 


Access violation 




1 


60-61 


Illegal or Unimplemented instruction j 


1 


62-63 


Reserved 








The even numbered bits in the bit pairs are the exception handler 
enable bits. These bits, when enabled, allow the program to vector to 
either a system supplied exception handling procedure or to a user 
supplied procedure on the occurrence of the associated exception. If 
the exception handler enable bit is disabled, the instruction that 
generated the exception delivers a default result to the destination 
operand. The details of this mechanism are discussed in Section 2.5, 
"Exceptions". The "Exception Enable Default" column in the table 
specifies the state of the exception handler enable bits on process 
startup . 



2.3 PROCEDURE CALLS 



ELXSI procedure calls reference and deallocate stack frames in a manner 
that is simpler, faster, and with less overhead than traditional 
approaches. Basically, a procedure explicitly allocates its own stack 
space before making any procedure calls, and places, rather than 
pushes, any data items it needs to save onto the stack. When the 
procedure calls a nested procedure, the CALL instruction places the 
return PC into the first 32-bit word of the allocated stack space and 
branches to the nested procedure. The nested procedure likewise 
allocates its own stack space. On exiting, the nested procedure 
deallocates its local stack frame (with the EXIT instruction) and the 
return address in the caller's stack frame is automatically placed into 
the PC. Control then resumes with the calling procedure. 
Alternatively, the "branch through register" instructions may be used, 
but stack frame allocation and deallocation support must be provided by 
the user. 
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This section discusses the general case of procedure calls and exits. 
Chapter 12, "Flow of Control Instructions", describes the instructions 
in detail. The special cases of interrupts and breakpoints may be 
found in Section 2.4, "Interrupts and Breakpoints". 

On process creation, a space in virtual memory is allocated as the 
stack area that starts at a base address and grows towards low memory. 
This is illustrated in the below diagram. The Stack Pointer (SP) , 
register 15, points to both the top of the stack and the stack frame 
base address. When a procedure is entered, it explicitly allocates a 
stack frame by subtracting from the SP the required stack frame space. 
The new low address of the stack frame is the stack frame base address, 
the top of stack, and the contents of SP. (The stack pointer is 
initialized to the stack space base address on process startup.) 



] -> Current stack Frame -> ] ] 



SP ] Stack space 

base address 



< lower memory addresses 

< stack grows in this direction 



An example of the call/exit protocol is shown below. It has a main 
procedure with 64 bytes of local storage, calling a nested procedure 
with 24 bytes of local storage. Upon entry to the main procedure, it 
is assumed that the stack is empty so that SP points to the stack base. 
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The outline for the code is 



MAIN PROC: 



subtract 64 from SP (explicitly allocate stack frame) 



call NESTED PROC 
i 



NESTED PROC: 



subtract 24 from SP (explicitly allocate stack frame) 



EXIT 24 (deallocate stack frame) 



First, the MAIN_PR0C code allocates its local stack frame. Since the 
stack grows towards low memory, this is accomplished by subtracting 64 
from SP. SP now points to the beginning of the current local stack 
frame and to the top of stack, which is now STACK_BASE-64. The stack 
now looks like: 



<- 
<- 



_beginning of current local 
stack frame' 



v 
-+- 



MAIN Stack Frame 



SP 



STACK BASE 



<" 
<" 



lower memory addresses 

stack grows in this direction 



The first 32 bits of the allocated local stack frame hold the space for 
the return Program Counter (PC) value. As this location is the current 
top of stack, it is pointed to by SP. When MAIN_PROC does call 
NESTED_PROC, the CALL instruction places the return PC in this location 
and replaces the contents of the Program Counter with the address of 
the first instruction in NESTED PROC. The "return PC" is the address 
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of the instruction following the CALL instruction, that is, the 
location for resuming execution after the return from the called 
procedure . 

NESTED_PROC allocates its stack frame in a similar fashion. By 
subtracting 24 from SP, the SP now equals STACK_BASE - (64+24), and the 
stack looks like: 



i 



beginning of current local stack frame 



v 
<__+ + + 

; NESTED SF \ MAIN Stack Frame ] 
<; — + + + 



_SP | _return PC ! Stack space base 



stored here 

< lower memory addresses 

< stack grows in this direction 



The last instruction in NESTED_PROC is an EXIT 24 instruction. This 
instruction first adds 24 to SP, thus deallocating its local stack 
frame. The SP now points to the top of stack for MAIN_PROC. The 
32-bit return PC pointed to by SP is then placed into the program 
counter, and control is returned to MAIN_PROC. 

Note that since the SP always points to the first data item in the 
current stack frame, other data items may be simply addressed by the 
base register + displacement addressing modes, which include addressing 
modes 8 and 9 that are designed for this purpose. 

It can be seen that the ELXSI architecture varies from the traditional 
approach in two respects. First, the local stack frame is assumed to 
run from low towards high memory addresses, thus allowing SP to serve 
as both top of stack pointer and current stack frame pointer. The 
second difference is when and where the local stack frame size is 
stored. 

In summary, data items are addressed by the lowest byte address they 
occupy in virtual memory, the stack grows toward low memory, and the 
beginning of a local stack frame is the address of the lowest byte in 
the frame. The calling procedure must explicitly allocate stack space 
for itself, otherwise the return address will be destroyed by any 
nested procedures that are called. 
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It is good practice to never store data in a space where stack growth 
may occur, as interrupts use this area to store part of the process 
state. The data and stack spaces are described in more detail under 
Memory Organization. 



2.4 INTERRUPTS AND BREAKPOINTS 

This section presents an overview of the environment in which an 
interrupt occurs. A more complete description may be found in the 
discussion on the message system in Chapter 13, "Inter-Process 
Communications" . 

Information from sources external to the process may only enter the 
process through the message system. A process will trap to an 
interrupt handler if the process is in a state that allows interrupts 
to occur and if the message is received on a designated interrupt 
channel. On an interrupt, the execution of the BREAKPOINT instruction, 
or after the execution of an instruction following the BXIT instruction 
with single stepping enabled, these events will: 



1. Allocate a stack frame to save the process data. For 
BREAKPOINT/SINGLE STEP, subtract 136 from the SP. For 
interrupts, subtract 144 from the SP. 

2. Place the PC of the next instruction onto the stack. The PC 
resides in the lower 32 bits of the 64-bit word placed onto the 
stack . 

3. For interrupts only, place the current local priority onto the 
stack (64 bits - the priority occupies the low order 4 bits) . 

4. Place Registers RF down to RO on the stack. 

5. Set RO to the memory address of the saved PC in the stack. 

6. Set Rl to the memory address of the saved RO in the stack. 

7. For all interrupts, branch to execute the interrupt handler (and 
ignore the remaining steps) . 

If a BREAKPOINT or the result of BXIT with single stepping enabled 
(Debugger entry) then set R2 to the following entry reason code 

Code Reason 

BREAKPOINT 

1 BXIT with single stepping enabled 

2 Execute address break 

3 Read data break 

4 Write data break 
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8. Set R3 to the memory address of the instruction just executed 
(old PC) or to zero if single step. 

9. Set R4 to the memory address of the data causing the data break. 
Set to zero if not a data break. 

10. Branch to enter the Debugger. 



After the breakpoint/single step save is complete, the stack appears as 
follows : 

Stack after BREAKPOINT/SINGLE STEP save of process data 

Definitions: 

SPb = stack pointer before break occurred 
PCb = program counter before break occurred 

Register contents: 

RF = SPb - 128 - 8 (or current SP) 

R0 = SPb - 8 (or current SP+128) 

Rl = SPb - 128 - 8 (or current SP) 

R2 = reason code 

R3 = address of instruction just executed 

(zero for single step) 
R4 = memory address of data causing break 

Stack contents: 

SP + 128 : saved PC 

SP + 120 : saved RF (SP) 

etc. 

SP + 8 : saved Rl 

SP + : saved R0 



Rl R0 holds address of return PC 

i 

i 
v 



■ i 

i i 



! saved [ . . . j saved | return [ Stack frame J ... | Base of 



! RO | | RF | PC | interrupted J | stack J 
+ .+ + + + + + 

A A 

! Current SP ] SP before break 

< Stack grows Higher memory addresses > 



2 
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The invoked Debugger procedure can receive the saved PC and GPRs as 
parameters and may modify the saved state before exiting. After the 
Debugger has built its stack frame, the stack looks like: 

Stack with DEBUGGER Stack Frame added 

Rl RO 
i i 
i i 

v v 

+ + + + + + + 

] Handler ' s j 16 regs J Return ] Stack frame ] ... ] Base of J 
J stackframe ] saved j PC ] interrupted ] ] stack \ 

+ + + + + + + 

A A 

! sp | spb 

< Stack grows Higher memory addresses > 



On exiting from the handler, the BXIT instruction deallocates the 
handler's stack frame, restores and deallocates the 16 registers and 
the PC, and returns to the interrupted process. 



Following are the stack and registers after the interrupt save is 
complete : 

Stack after INTERRUPT save 

Definitions: 

SPb = stack pointer before interrupt occurred 
PCb = program counter before interrupt occurred 
OLP = old local priority 



Register contents: 



RF = SPb - 128 - 16 (or current SP) 
RO = SPb - 8 (or current SP+128+8) 
Rl = SPb - 128 - 16 (or current SP) 
R2 = receiving funnel ID (on an interrupting channel) 



Stack contents: 



SP + 136 : saved PC 

SP + 128 : saved old local priority 

SP + 120 : saved RF (SP) 

etc. 

SP + 8 : saved Rl 

SP + : saved RO 



- 10 
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The stack after the interrupt save is 



Rl 



i 
i 

v 



i 
i 

V 



RO holds address of return PC 



saved j 


. . | saved | saved 1 return | Stack frame ] . 


. | Base of 


RO ! 


| RF 1 OLP | PC | interrupted | 


| stack 



Current SP 



< Stack grows 



,_ SP before interrupt 

Higher memory addresses > 



The invoked interrupt procedure can receive the saved PC, old local 
priority, and GPRs as parameters, but it is not recommended that 
interrupt handlers modify the saved state before returning. After the 
handler has built its stack frame, the stack looks like: 

Stack with Handler Stack Frame added 



i 
v 



Rl 



RO 



i 
v 



j Handler ■ s 
! stackframe 



16 regs 
saved 



saved 
OLP 



Return 
PC 



Stack frame 
interrupted 



I Base of ! 



i 

i 

-+- 



stack 



SP 



SPb 



< Stack grows 



Higher memory addresses > 



On exiting from the interrupt routine, the IXIT instruction deallocates 
the handler's stack frame, restores and deallocates the 16 registers, 
old local priority, and the PC, performs the activities that are 
required for exiting from an interrupt (such as executing the 
SET. LOCAL. PRIORITY function), and returns to the interrupted process. 

This is note for those readers who may write code which modifies data 
structures that are shared with an interrupt handler. Compilers 
written for the ELXSI will in general perform register tracking. This 
may result in references to a datum shared with an interrupt handler 
not actually loading that datum from memory, because it already resides 
in a register. If an interrupt handler is invoked between two such 
references and modifies the datum, the value in the register may not be 
current. This is, of course. 



11 
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Refer to the appropriate ELXSI Language User's Guide for information on 
how to maintain the integrity of such shared data items. 



2.5 EXCEPTIONS 

Exceptions provide a convenient mechanism to call a special procedure 
in the event of some defined condition or relation. These exceptions 
fall into two general classes: user-interceptable exceptions and 
non-interceptable exceptions (faults) . Non-interceptable exceptions 
are used by the system for such conditions as page faults. Typically 
these exceptions are corrected by the system and are transparent to the 
faulting process. 

This section covers the class of user interceptable exceptions. The 
Program Status Word always records the occurrence of such exceptions. 
The user may establish several courses of action that include the 
following: 

1. Default. The system will generate a fabricated result for the 
instruction that generated the exception if the user has 
disabled the exception handler enable bit associated with the 
exception. 

2. Call the system exception handler. If the user has enabled the 
exception handler enable bit, a system supplied exception 
handler is invoked which will enter the Debugger if selected or 
cause the process to terminate. 

3. Call a user supplied exception handler. The user may write an 
exception handler to replace the system exception handler. 
Intrinsics are provided for this purpose. 

Unless otherwise specified, program control ' resumes at the instruction 
following the instruction that generated the exception. 



2.5.1 User Interceptable Exceptions 

User interceptable exceptions may be classified as follows: 

1. Architectural Exceptions. Exceptions of this type are detected 
by the system hardware and invoke the system exception handler 
as well as, optionally, a user supplied exception handler. 
These include all bit pair entries in the PSW listed in Table 
2-1. 

2. Software Exceptions. Software exceptions are generated by the 
"generate exception" instructions described in Chapter 10, 
"Relational Test Instructions" , and by the EXCEPTION 
instruction. The generate exception instructions test a user 
defined relation and cause an exception if the relation is true. 
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Additionally, the user may specify exception subclasses within 
these instructions that will interrupt to user supplied subclass 
exception handlers. 

The difference between these and the architectural exceptions 
lies in the user requirement to supply the exception handler and 
to keep track of unique exception types. The general status of 
this type of exception is maintained in the PSW as bit pair 
56-57. 



2.5.2 Exception Mechanism 

An instruction that causes an exception with the associated exception 
handler enabled will cause the system to generate a message. This 
message, directed into a standard funnel of the process, contains the 
instruction that generated the exception and other information some of 
which may be defined by the user. Arrival of the message on the funnel 
causes an interrupt that invokes the system exception dispatcher. The 
dispatcher may then pass the message, after some modification, to the 
correct system exception handler or to a user supplied exception 
handler, which resolves the problem and returns control to the 
interrupted procedure. The exception software resides in the code 
space of the process. 

The standard exception funnel is essentially an input port that is 
attached to channel 1 of the same process that generated the exception. 
Its purpose is to receive incoming exception messages generated by the 
system. The channel to which the funnel is attached is enabled for 
interrupts, such that the arrival of a message will interrupt the 
faulting process and invoke the system exception dispatcher specified 
by the funnel's interrupt vector. 

The system exception dispatcher is the procedure pointed to by the 
interrupt vector associated with the standard exception funnel. This 
procedure brings the exception message into the process space, 
determines the type of exception generated, and either calls the 
appropriate system supplied exception handler or a user supplied 
exception handler, if provided. The exception message also contains 
information on other exceptions that may have occurred for the 
instruction, and calls these additional procedures based on the 
priorities of the incoming exceptions. 

The called procedure handling the exception may manipulate the data 
that has been placed on the stack by the exception dispatcher. When 
the procedure exits, eventually to the interrupted code, the stack 
containing the corrected information will be deallocated and restored 
to the appropriate registers. (Target operands in memory are corrected 
in the exception handling procedures.) 
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2.5.3 Exception Message Description 

The message data block has the following format upon arrival into the 
standard exception funnel: 



Table 2-2. Exception Message Format 
12 3 4 5 6 





1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 



Instruction (72) 


--> 


— > J unused (48) 




J res (8) |exc (8) 


Program Counter (32) | 


unused (32) 


unused (64) 


unused (64) 


Value of source operand 1 


(low) 


(64) 


unused (64) 


Value of source operand 2 


(low) 


(64) 


Actual result (high) 


(64) 




Actual result (low) 


(64) 




unused (64) 


unused (64) 


Variant Part (64) 



The fields in the message area have the following meanings: 

Instruction: This field contains the entire instruction that caused 
the exception. The instruction is left justified. 

Exception Code: This field has a value from to 255 and uniquely 
identifies the type of exception to be processed. Refer to Table 2-3 
for the exception codes. 
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Table 2-3. Exception Message Codes 



Code 



Interceptable Exceptions 




1 
2 
3 
4 
5 
6 

7-19 

20 
21 
22 



Integer overflow 
Integer Divide by Zero 
Floating Point Overflow 
Floating Point Underflow 
Floating Point Divide by Zero 
Floating Point Invalid Operation 
Floating Point Inexact Result 

Reserved 

Software generated exception 

Access violation 

Illegal or Unimplemented instruction 



The system exception dispatcher extracts this field and adds 256 to the 

code to pass to the exception handlers. This allows the lower 256 

values to be used for subclass exception codes specified in the 
appendages of the generate software exception instructions. 



Program Counter: The Program Counter is the 32-bit virtual address 
the instruction that raised the exception. 



of 



Variant Part: Several of the exceptions, including the software 
generated exceptions, provide specific values relevant to the 
instruction and the exception type. 



The parts of the exception message which are valid for 
are defined below. 



each exception 



INTEGER OVERFLOW 



! Message Field ] 


Contents of Message Field 


! exception code [ 





! instruction ] 


instruction causing exception 


j program counter J 


instruction causing exception 


] source operand 1 J 


none 


| source operand 2 ' 


none 


J actual result - high ] 


none 




mul may provide high word of result 


| actual result - low ] 


mod 2**64 of result 


| variant part [ 


none 
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INTEGER DIVIDE BY ZERO 



[ Message Field 


] Contents of 


Message 


Field 


| exception code 


| 1 






] instruction 


I instruction 


causing 


exception 


[ program counter 


I instruction 


causing 


exception 


| source operand 1 


| none 






! source operand 2 


! none 






| actual result - high 


I none 






[ actual result - low 


I none 






[ variant part 


' none 







FLOATING POINT OVERFLOW 



] Message Field 


j Contents of Message Field 


! exception code 


! 2 


J instruction 


! instruction causing exception 


J program counter 


I instruction causing exception 


I source operand 1 


! none 


\ source operand 2 


J none 


J actual result - high 


! valid if extended precision 


J actual result - low 


[ scaled result 


] variant part 


| none 


] comments 


J results depend on precision 



FLOATING POINT UNDERFLOW 



[ Message Field 


] Contents of Message Field 


j exception code 


! 3 


\ instruction 


| instruction causing exception 


| program counter 


! instruction causing exception 


j source operand 1 


] none 


] source operand 2 


] none 


1 actual result - high 


j valid if extended precision 


j actual result - low 


] scaled result 


\ variant part 


\ none 


\ comments 


[ results depend on precision 
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FLOATING POINT DIVIDE BY ZERO 



', Message Field 


] Contents of 


Message 


Field 


! exception code 


! 4 






] instruction 


I instruction 


causing 


exception 


\ program counter 


] instruction 


causing 


exception 


[ source operand 1 


I none 






[ source operand 2 


| none 






! actual result - high 


| none 






J actual result - low 


| none 






! variant part 


] none 







FLOATING POINT INVALID OPERATION 



Message Field 


| Contents of Message Field 


exception code 


! 5 


instruction 


J instruction causing exception 


program counter 


\ instruction causing exception 


source operand 1 


] system handler may provide 


source operand 2 


] system handler may provide 


actual result - high 


] none 


actual result - low 


| none 


variant part 


] none 



FLOATING POINT INEXACT RESULT 



Message Field 


| Contents of Message Field 


exception code 


! 6 


instruction 


| instruction causing exception 


program counter 


1 instruction causing exception 


source operand 1 


\ none 


source operand 2 


| none 


actual result - high 


! valid if extended precision 


actual result - low 


j scaled result 


variant part 


j none 


comments 


[ results depend on precision 
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SOFTWARE EXCEPTION (includes compare and generate exception) 



| Message Field 


Contents of Message Field 




] exception code 


20 




] instruction 


instruction causing exception 




J program counter 


instruction causing exception 




; source operand 1 


sub-code rx for EXCEPTION instr 






sub-code from appendage for CMP 


instr 


I source operand 2 


exception data rz for EXCEPTION 
for CMP instr 


instr 


! actual result - high 


none 




I actual result - low 


none 




[ variant part 


none 





ACCESS VIOLATION - data, instruction 



[ Message Field 


Contents of Message Field 


| exception code 


21 


] instruction 





! program counter 


data - instruction causing exception 




instr - last instruction to execute 


! source operand 1 


none 


] source operand 2 


none 


| actual result - high 


none 


! actual result - low 


none 


J variant part 


none 


| comments 


cannot supply instruction because of 


i 


execute only access rights. 



ILLEGAL/UNIMPLEMENTED INSTRUCTION 



Message Field 


[ Contents of 


Message 


Field 


exception code 


! 22 






instruction 


I instruction 


causing 


exception 


program counter 


J instruction 


causing 


exception 


source operand 1 


] none 






source operand 2 


! none 






actual result - high 


! none 






actual result - low 


[ none 






variant part 


! none 
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2.6 MEMORY ORGANIZATION 

This section describes the virtual addressing space available to a 
process and its allocation. 



2.6.1 Virtual Memory Space 

A general virtual address is 32 bits in size. The addressing space (4 
gigabytes) is considered by the memory manager to have four subspaces 
of one gigabyte each. These subspaces are Private (2), Public, and 
Reserved. The two most significant bits of the address are used to 
identify the address space: 

Table 2-4. Virtual Memory Allocation 



j MSB | Virtual Memory allocation , 

| j Private Space J 

' oi ' ' 

! 10 ! Public Space ! 



11 , Reserved 



Private space, of up to two gigabytes for each process, is managed as 
two separate and independent subspaces but appears to a process as a 
single, contiguous space. The first subspace, known as PO (MSB 00), 
grows towards higher memory, while the second subspace, known as Pi 
(MSB 01), grows towards lower memory. The memory mapping scheme splits 
up a process between these two subspaces to allow the code/stack area 
and the data area to grow towards each other. 

The actual use of this private space includes the following types of 
addressable objects: 



o Code. This includes all the private instructions which are to 
be executed by the process. Private code usually consists of a 
program together with any unshared libraries. Code is normally 
marked with execute-only access and, therefore, may not be 
modified. This provides the advantages of re-entrancy and 
maintainability . 

o Static data. Static data has a lifetime equal to that of the 
program and does not change in size during execution. This 
corresponds to the global data declarations of most languages. 
The actual size of static data will vary depending on the 
program being executed. 
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o Dynamic Data. Dynamic data changes in size and application 
during the life of the program. The major uses of dynamic data 
are for the Pascal heap area, control blocks for the file 
system, and other run-time library procedures. Management of 
dynamic data space is the responsibility of the software. For 
example, the Pascal compiler is responsible for any garbage 
collection that may be necessary in its heap area. 

o Stack Data. Stack data has a lifetime equal to the life of the 
procedure which defines it. This data includes all variables 
that are declared locally within a procedure or subroutine. 
Stack data is added to the stack as a procedure is called, and 
is deleted from the stack when the procedure terminates. 

Stack data and Dynamic data both change in size during the execution of 
a program. The ultimate size of each of these classes of data is not 
known before the program is actually executed. For this reason, 
separate these two classes of data as far as possible and let them grow 
towards each other; this leaves the largest possible open growth space 
between them. The standard organization of private space is 
illustrated below. 
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Table 2-5. Private Space Allocation 
Private Space allocation 



Page 

A few pages 
(fixed) 



Many pages 



Many pages 



Many pages 



Many pages 



not allocated 



Special common data 
(for run-time libraries) 



Static Data 



Dynamic Data 



Dynamic Growth 



Stack Growth 



Stack Data 



Code 



Constants 



Debug Records 
Public Space 



MSB 10 



MSB 11 



Reserved 



Page zero cannot be allocated, 
bugs that reference address zero. 



This is to catch common programming 
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The special common data area contains pointers for the run time 
libraries. These pointers are used to locate the so-called "own" 
variables that actually reside in the dynamic data area. An example of 
these own variables is the file control blocks used by the in-process 
part of the file system. 

The public subspace, called PUB, (addresses with MSB = 10) is shared 
with all processes and is used primarily for system library code. The 
public subspace grows towards higher memory. The last subspace is 
reserved for future expansion. 



2.6.2 Page Haps 

For each subspace (such as those described above) there is a map which 
is used by the hardware to translate a virtual address to a physical 
address. The Page Map contains Page Map Entries (PMEs) which describe 
the attributes of a page. 

Virtual space is logically broken up into pages of 2 Kbytes (2048 
bytes) each. For every virtual page there may be a physical page 
allocated on disk by the memory manager that holds the data. A page 
"in memory" is a copy of this data in physical memory, a necessary 
condition for utilization by the instruction set. A page that is 
referenced but not "in memory" will generate a page fault, causing the 
memory manager to bring the page in off the disk so that the CPU can 
continue executing for the faulting process. 

The page map will be large if the space it describes is large. 
Therefore, it is necessary to break the page map itself into pages to 
allow effective management of main memory. This is achieved by a 
hierarchy of page maps. A single level page map is capable of handling 
small subspaces up to 512 KBytes. When space requirements increase, a 
second level is created with its first descriptor pointing to the first 
level page. The other PMEs on this second level define other first 
level pages as the need for their existence becomes apparent, to a 
maximum of 128 Mbytes. The third level is created in a similar fashion 
for subspaces larger than 128 Mbytes. The conceptual similarity of the 
various sizes of subspace makes it easy to expand a subspace even as it 
crosses one of the boundaries separating the three levels. For 
example, if a process needs to get another page added to a 512 Kbyte 
subspace, it will first be checked to see that no administrative size 
limits have been exceeded and then the memory manager will create a 
second-level page map. 
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2.6.3 Page Map Entry (PME) 

The page map entry is a generalized descriptor of a page in its current 
state. Refer to Table 2-4 on the following page. 

There are essentially two forms of the PME depending on whether the 
page is in memory or not. This is specified by the "inPhysicalMemory" 
bit. If the page is in memory, the PME specifies the physical address 
of the page image. If the page is absent from memory, then the memory 
manager checks bit 11. If bit 11 = 0, then the PME specifies the disk 
address of the page. A disk address consists of a disk identifier and 
a sector address. 

The PME may be read with the READ. PME instruction. The following bits 
may be modified with the MODIFY. PME instruction: 

maintenanceBit 
readTraceBit 
writeTraceBit 
executeTraceBit 
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Table 2-6. Page Map Entry 





16 


1 


17 


/ 


•• 


/ 




1 


35 




36 




37 


1 


38 


/ 


• * 


/ 




1 
1 


62 


1 
1 


63 



00 <— 


inResidentSet 


boolean "present" bit 




01 


i 
i 


readAllowed 


i 

i 


02 


accessRights \ 


writeAllowed 


i 
i 


03 


i 
i 


executeAllowed 


i 
i 




— Page Map Level 1 — 


— Page Map Levels 2,3 


— 


04 


copyOnWrite 


J j inMemoryPMEs 


i 


05 


cacheable 


! ! (use 9) 




06 


referenced 






07 


maintenanceBit 






08 


readTraceBit 






09 


writeTraceBit 






10 


executeTraceBit 






11 


preserved for MM> 






12 


origCacheable 






13 


<unused> 


\ j expandCacheable 




14 


<unused> 


\ ] <unused> 


i 



15 <-- 



inPhysicalMemory 

case inPhysicalMemory of 

TR UE FALSE 

[ pageFrameNumber ] j fileAddress (use 48) 
! (use 20) J | {bit 11 = 0} 



/ 



// 
// 



1 
1 
1 




i i 
i i 
i i 


1 


grandPageAddre s s 


i i 
i i 


1 


(use 27) 


i i 
i i 


/ 




// 


/ 

1 

1 
1 




// 

i i 

■ i 
i i 



I 

/ 



/ / 



1 

/ 


1 

/ 


/ 

1 

1 
1 


/ 

1 
1 
1 
1 
1 
1 
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3 DATA REPRESENTATIONS 



The ELXSI architecture supports six classes of data representations, as 
listed below: 



o INTEGER 

O LOGICAL 

O FLOATING POINT 

O CHARACTER 

O STRING 

O NUMERIC STRING 



For the illustrations in this chapter, the most significant bit is 
bit 0, shown as the leftmost bit. Bytes are represented in a similar 
fashion in both registers and memory. Data resides in memory from low 
address to high address, with the low address as byte zero. Register 
data is always a 64-bit quantity, which means that memory operands are 
sign or zero extended and right justified when loaded into a register. 
Addressing formats are discussed in Chapter 4, "Instruction Set 
Composition". 



3.1 FLOATING POINT 

ELXSI Floating Point representations conform to the proposed IEEE 
Standard for Binary Floating-Point Arithmetic. Three floating point 
number representations are provided: single (32 bits) , double 
(64 bits) and double extended (80 bits) . All three forms may exist in 
either a register or in memory. 

A floating point operand is composed of a sign bit, a significand and 
an exponent. The significand is an unsigned number with a value 
greater than or equal to zero, and less than two. 

The integer bit of the significand is physically present in the 
extended double precision storage formats, but the bit is not present 
in the single and double precision forms. The implied state and 
location of the integer bit in these cases is referred to as the 
"hidden bit". 

The exponent range for single and double precision starts at 1 to 
enable the encoding of the hidden bit. If the exponent is zero, the 
hidden bit is inferred to be zero, and the number is denormalized (or 
zero if the number is equal to zero) . The range for Double Extended 
starts at zero. 



DATA REPRESENTATIONS 

3.1.1 Terminology 

The following are terms used in this section: 

o Biased exponent: The sum of an exponent and a constant (bias) 
chosen to make the biased exponent ' s range non-negative . 

o Denormalized number: A non-zero floating point number whose 
exponent is the minimum value for the format, and whose leading 
significand bit is zero. 

o Exponent: The component of a binary floating point number that 
normally signifies the integer power to which two is raised in 
determining the value of the number. It is represented by an 
"e" . 

o Fraction: The field of the significand that lies to the right 
of its implied binary point. It is represented by an "f". 

o Infinity: The ELXSI uses the affine closure form of infinity. 
It may be illustrated by a straight number line with a positive 
infinity at one end and a negative infinity at the other end. 

o NaN: Not a number. There are two types of NaN's, signaling and 
quiet. These symbolic entities are used to check for invalid 
data or certain arithmetic enhancements. 

o Quiet NaN: Quiet NaNs are propagated through all arithmetic 
operations to allow the retrospective diagnosis of invalid 
results. These are represented with the first bit to the right 
of the binary point equal to zero. 

o Signaling NaN: Signaling NaNs signal the INVALID OPERATION 
exception whenever they appear as operands. These allow values 
for uninitialized variables or arithmetic enhancements, and are 
represented with the first bit to the right of the binary point 
equal to one. 

o Significand: The component of a binary floating-point number 

that consists of an explicit or implied leading integer bit to 

the left of the implied binary point, and a fraction field to 
the right. 

o Sign bit: The most significant bit of an integer or floating 
point representation that determines the sign of the operand. 
Otherwise, this bit is the most significant bit of any datum, 
and is represented by "s" . 
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3.1.2 Data Types 

The three floating point types. Single, Double, ana Double Extended, 
are illustrated below in both register and memory form. Single or 
Double precision operands require one register. Double Extended 
operands require two registers, R and R+l, with bit of a memory 
operand aligning with bit of R and bit 127 aligning with bit 63 of 
R+l. 



3.1.2.1 Single Precision 

The Single Precision floating point number is represented in a 32-bit 
field with 1 sign bit, 8 exponent bits, 23 significand bit's and 1 
hidden bit. 

The exponent may range from -126 to 127. The actual exponent is biased 
by 127 so that it is always positive. As such, the smallest exponent 
value (-126) is represented by an actual exponent of 1 (or zero if 
denormalized) . An actual exponent of 255 is used for representing 
infinities and NaN's. 

The hidden bit is assumed to be immediately to the left of bit 9. The 
binary point lies between the hidden bit and bit 9. 



Single Precision in Memory 



I seeeeeeee f f f f f f f f f f f f f f f f f f f f f f J 

»A A»» __A 

III I 



Significand, fractional part: 
Bits 9 to 31 



_Hidden bit (not physically present) 



Exponent: Range -126 to 127. Bits 1 to 8 



Sign bit: if positive, 1 if negative. Bit 
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Single Precision in Register 



<unused)> 



seeeeeeee f f f f f f f f f f f f f f f f f f f f f f J 



32 



39' 



63 



3.1.2.2 Double Precision 

The double precision floating point number is represented in a 64-bit 
field with 1 sign bit, 11 exponent bits, 52 significand bits and 1 
hidden bit. 

The exponent may range from -1022 to 1023. The actual exponent is 
biased by 1023 so that it is always positive. As such, the smallest 
exponent value (-1022) is represented by an actual exponent of 1 (or 
zero if denormalized) . An actual exponent of 2047 is used to represent 
infinities and NaN's. 



The hidden bit is assumed to precede bit 12. 
between the hidden bit and bit 12. 



The binary point lies 



Double Precision in Memory and Register 



seeeeeeeeeee f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f f 



.A A A___„ ,__. „___„„ . _, ___,_______.„.__ A 



Significand, fractional part: 
Bits 12 to 63 

Hidden bit (not physically present) 



Exponent: Range -1022 to 1023. Bits 1 to 11 



Sign bit: if positive, 1 if negative. Bit 
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3.1.2.3 Extended Double 

The extended double floating point number (80-bit) is represented in a 
128-bit field with 1 sign bit, 15 exponent bits, 64 significand bits 
and 48 unused bits. There is no hidden bit. 

The exponent may range from -16383 to 16383. The actual exponent is 
biased by 16383 so that it is always positive. As such, the smallest 
exponent (-16383) is represented by an actual exponent of zero. An 
actual exponent of 32767 is used to represent infinity and NaN's. 

There is no hidden bit. The binary point lies between bit 64 and 65. 
If bit 64 =1, the the number is Normal. If the exponent = and bit 
64 = 0, then the number is Denormalized . If the exponent is not equal 
to or 32767, and bit 64 = 0, then the number and all operations on it 
are undefined. 



Double Extended in Memory and Register, High Order Word, 
seeeeeeeeeeeeee <unused> 



Unused. Bits 16 to 63 

Exponent: Range -16383 to 16383. Bits 1 to 15 

Sign bit: if positive, 1 if negative. Bit 



Double Extended in Register and Memory, Low Order Word. 

iffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff J 

—————————————————— —————— _———_____— ___— ————— _— _________ *■ 

Fractional part of Significand. Bits 65 to 127 
Binary integer part of Significand. Bit 64 
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3.1.3 Operand Classes 

The five operand classes characterize an operand through values in the 
exponent and significand fields. This information is summarized in the 
following table. The "i" and "f" table headers in the Significand 
field specify the integer and fractional parts respectively. Note that 
normalized numbers use a biased exponent such that the exponent will 
always be positive. 



Table 3-1. Operand Classes 



Significand 



Operand Class 



Data Type 



; Exponent 



Value 



zero 



, Single Precision , 
| Double Precision | 
! Extended Double ! 









x 
x 





zero 
zero 
zero 



denormalized 
number 



J Single Precision | 
[ Double Precision | 
! Extended Double I 









nonzero 
nonzero 
nonzero 



normal (ized) 

nonzero 

number 



, Single Precision , 
,' Double Precision ! 



, Extended Double , 



254 

2046 

32766 



x 

1 



any 
any 
any 



infinity 



| Single Precision \ 



, Double Precision | 
[ Extended Double \ 



255 

2047 

32767 



i i 

i i 

i i 

i i 



zero 
zero 
zero 



, quiet 

] not-a-number 

! (NaN) 

] symbol 



Single Precision 
Double Precision 
Extended Double 
Extended Double 



255 

2047 

32767 

32767 



x 
x 



1 



, nonzero 

| nonzero 

] nonzero 

! any 



signaling 
not-a-number 
(NaN) 
symbol 



Single Precision 
Double Precision 
Extended Double 
Extended Double 



255 | x i 1 ; any 

2047 | x | 1 ! any 

32767 I | 1 ] any 

32767 ; 1 I 1 I any 
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3.1.4 Rounding Modes 

There are four rounding modes that may be selected. The rounding modes 
are determined by the rounding mode bits set in the Process Status 
Word. 

1. Round to nearest even. In the halfway case, round so that the 
low order bit of the result is zero. Over a large number of 
roundings the direction will be unbiased. This is the default 
rounding mode. 

2. Round to zero. Truncate magnitude. 

3. Round toward positive infinity. 

4. Round toward minus infinity. 



The two infinities (positive and negative) are considered to be at the 
opposite ends of a number line. (Positive and negative zero have the 
same value) . 

+0 
-inf negative numbers [ positive numbers +inf 



3.1.5 Predicates and Relations 

It is possible to compare all floating point numbers in all formats. 
Comparisons are exact and never overflow or underflow. The four 
mutually exclusive relations are: 



< 

> 

An unordered relation occurs when one or more of the operands is a NaN. 
(A NaN is unordered to everything, including itself.) The relational 
test instructions use a 4-bit compare condition field (ccf) with the 
values indicated in the table to test for the corresponding relation. 



UNORDERED 


U 


LESS THAN 


L 


EQUAL 


E 


GREATER THAN 


G 
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Table 3-2. Predicates and Relations 





PREDICATES 






RELATIONS 




| ad hoc 


symbol 


ccf 


! u 


L 


E 


G 


! > 


G 


1 


! f 


F 


F 


T 


j = 


E 


2 


! f 


F 


T 


F 


: >= 


EG 


3 


! f 


F 


T 


T 


! < 


L 


4 


! f 


T 


F 


F 


; <> 


LG 


5 


! f 


T 


F 


T 


! <= 


LE 


6 


! f 


T 


T 


F 


; <=> 


LEG 


7 


! f 


T 


T 


T 


! ? 


U 


8 


! T 


F 


F 


F 


! ?> 


UG 


9 


! t 


F 


F 


T 


! ?= 


UE 


10 


! t 


F 


T 


F 


! ?>= 


UEG 


11 


! t 


F 


T 


T 


! ?< 


UL 


12 


1 T 


T 


F 


F 


: ?<> 


ULG 


13 


1 T 


T 


F 


T 


; ?<= 


ULE 


14 


! t 


T 


T 


F 


: ?<=> 


ULEG 


15 


| T 


T 


T 


T 



Refer to Chapter 10, "Relational Test Instructions", for a discussion 
on the Relational Test instructions. 



3.1.6 Exceptions 

This section describes the conditions under which the user 
interceptable architectural exceptions are generated. Also provided 
are the default results if the exception handler is not enabled, and 
the results supplied by the system exception handlers. 

The following exceptions are mutually exclusive: 

o Floating Point Invalid Operation 

o Floating Point Divide by Zero 

o Floating Point Underflow 

o Floating Point Overflow 



The Floating Point Inexact Result exception may coincide with either 
Underflow or Overflow. In this case, the Underflow or Overflow has 
precedence. If both exceptions occur and only one exception handler is 
enabled, then the message appropriate to the enabled exception is sent 
to the exception handler along with the information that both 
exceptions occurred. If both or neither of the exception handlers are 
enabled, the action appropriate to the exception with priority is 
carried out. 
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3.1.6.1 Floating Point Overflow 



If the exception handler is disabled, the result 
rounding mode as shown in the following table: 



depends on the 



Table 3-3. Floating Point Overflow Result Matrix 
with Disabled Exception Handler 



Rounding Mode 



Sign of Result 



Returned Value 



Round to Nearest Even 
Round to Zero 
Round to Plus Infinity 
Round to Minus Infinity 
Round to Plus Infinity 
Round to Minus Infinity 



x infinity with sign 

x largest normalized with sign 

1 largest normalized with sign 

largest normalized with sign 

infinity with sign 

1 infinity with sign 



If the system exception handler is enabled, the system will calculate 
the infinitely precise result and round it to the precision of the 
destination. This result is then scaled and is passed to the exception 
handler, as follows: 



Single Precision 
Double Precision 
Extended Precision 



Actual result of exponent minus 192 
actual result of exponent minus 1536 
Actual result of exponent minus 24576 



3.1.6.2 Floating Point Underflow 

Exponent underflow is detected before rounding. If the exception 
handler is enabled, then the system will calculate the infinitely 
precise result rounded to the precision of the destination. The result 
is then augmented and passed to the exception handler as follows: 



Single Precision 
Double Precision 
Extended Precision 



Actual result of exponent plus 192 
Actual result of exponent plus 1536 
Actual result of exponent plus 24576 



If the exception handler is disabled in Flush to Zero mode, then the 
system will set the Underflow exception and deliver zero as the result. 
If not in Flush to Zero mode, then the system delivers a denormalized 
number as the default result. In this case, the Underflow exception is 
set only if the result is not exact (which will also set the Inexact 
Result exception) . 
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3.1.6.3 Floating Point Divide by Zero 

If the exception handler is disabled, then the result is infinity with 
appropriate sign (XOR the signs of the operands) . The system exception 
handler will terminate the process or enter the Debugger if enabled. 



3.1.6.4 Floating Point Invalid Operation 

An Invalid Operation exception occurs if an operation is attempted on 
an operand for which the operation is not defined, such as a floating 
point multiply with an unordered operand. If the exception handler is 
disabled, the default result for an Invalid operation is a Quiet NaN 
(Not a Number) whose significand is not necessarily related to the 
significand of either of the operands, even if one of them is a 
Signaling NaN. 

The canonical Quiet NaN is as follows: 



Single Precision 
Double Precision 
Extended Double 



7F80 0001 

7FF0 0000 2000 0000 

7FFF 0000 0000 0000, 8000 0100 0000 0000 



The system exception 
Debugger if enabled. 



handler will terminate the process or enter the 



3.1.6.5 Floating Point Inexact Result 

An inexact exception occurs if information is lost by rounding, or if 
infinity is delivered as the result of operations on finite operands. 
If the exception handler is disabled, the computed result is delivered. 
The system exception handler will terminate the process or enter the 
Debugger if enabled. 



3.2 INTEGER 



The ELXSI architecture provides for 8-, 16-, 32-, and 64-bit integers. 
Integers may be either signed or unsigned. If signed, the integer is 
represented in two's complement form, and the sign bit is bit 0. 
Integers are low-order adjusted when in registers. Memory operands 
loaded into registers are sign or zero extended to 64-bits as specified 
by the operation. 
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8-bit Signed Integer 



! siiiiiii ! 



16-bit Signed Integer 



[ siiiiiiiiiiiiiii ] 



15 

32-bit Signed Integer 
[ siiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ] 
31 




Not all types of integer operations are supported for all types of 
integers. Please see Section 6.1, "Multiple Precision Integer 
Arithmetic", for specific usage. 



3.2.1 Exceptions 

This section describes the conditions under which the user 
interceptable hardware exceptions are generated. Also provided are the 
default results if the exception handler is not enabled, and the 
results supplied by the system exception executioners. 
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3.2.1.1 Integer Overflow 

Integer overflow occurs with signed integer operations that generate 
results exceeding 64 bits, and with certain operations that attempt a 
store with overflow check. Operations generating an integer overflow 
will place the result into the target operand before checking the 
exception handler enable bit in the PSW. High order bits of the result 
that do not fit into the target operand are lost, as the result exceeds 
the modulus of the target. The system exception handler will terminate 
the process or enter the Debugger if enabled. 



3.2.1.2 Integer Divide by Zero 

This exception occurs with an attempt to divide by zero. If the 
exception handler is disabled, then the target operand remains 
unchanged without overflow. The system exception handler will 
terminate the process or enter the Debugger if enabled. 



3.3 LOGICAL 

A logical datum is a bit-string (array of bits) with length 8-, 16-, 
32-, or 64-bits. Bit-strings loaded from memory are low-order 
justified in the register and are unsigned. Immediate operands are 
sign extended to 64 bits when in a register. 



8-bit Logical 



! bbbbbbbb ! 



16-bit Logical 
| bbbbbbbbbbbbbbbb | 
15 

24-bit Logical 
J bbbbbbbbbbbbbbbbbbbbbbbb | 
23 
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32-bit Logical 

| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb j 
31 

40-bit Logical 

| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb J 
39 

48-bit Logical 

| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb J 
47 

56-bit Logical 

| bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb \ 
55 

64-bit Logical 

JbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbJ 
63 



Chapter 9, "Logical Instructions", provides additional information on 
utilization by the instruction set. 



3.4 CHARACTER 

Characters on the ELXSI are ASCII encoded bytes. Bits in a character 
are numbered from left to right, high order to low order, to 7. For 
the ASCII representations, bit of the byte is zero. A ' 1' in bit 
is presently undefined for an alternate character set. 
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The ASCII equivalence table may be seen below: 



Table 3-4. ASCII Equivalence 



Low 


Nibble 






High Nibble 






hex 




| 00 


10 


20 


30 


40 


50 


60 


70 




! dec 


! o 


16 


32 


48 


64 


80 


96 


112 


00 


! o 


| NUL 


DLE 


SP 





§ 


P 


- 


P 


01 


1 1 


J SOH 


DC1 


t 


1 


A . 


Q 


a 


q 


02 


! 2 


1 STX 


DC2 


ii 


2 


B 


R 


b 


r 


03 


! 3 


1 ETX 


DC3 


# 


3 


C 


S 


c 


s 


04 


! 4 


1 EOT 


DC4 


$ 


4 


D 


T 


d 


t 


05 


! 5 


! ENQ 


NAK 


% 


5 


E 


U 


e 


u 


06 


! 6 


j ACK 


SYN 


& 


6 


F 


V 


f 


V 


07 


! 7 


1 BEL 


ETB 


i 


7 


G 


W 


g 


w 


08 


! 8 


1 BS 


CAN 


( 


8 


H 


X 


h 


X 


09 


! 9 


1 HT 


EM 


) 


9 


1 


Y 


i 


y 


OA 


| 10 


i LF 


SUB 


* 


: 


J 


Z 


J 


z 


OB 


! 11 


! VT 


ESC 


+ 


r 


K 


[ 


k 


{ 


OC 


! 12 


1 FF 


FS 


i 


< 


L 


\ 


1 


1 

1 


OD 


! 13 


1 CR 


GS 


- 


= 


M 


] 


m 


} 


OE 


! 14 


; so 


RS 


. 


> 


N 


A 


n 


~ 


OF 


! is 


! si 


US 


/ 


7 





- 


o 


DEL 



3.5 STRING 

Type String is an array of ASCII characters. Strings may start on any 
byte boundary and have a maximum length of (2**31)-1 characters. Bytes 
in a character string are numbered from left to right, low memory 
address to high memory address, starting from 0. Refer to the 
Character data type for a description of the ASCII character. 



3.6 NUMERIC STRING 

A numeric string represents an unsigned decimal integer value through a 
character string. Each byte in the string must contain the ASCII 
representation of a decimal digit (Hex 30 through 39) . When in a 
register, leading and trailing decimal zeros may be represented by hex 
00 or hex 30. However, all ASCII instructions (CVT.IA, ASCII. ADD, 
ASCII. ADDC, ASCII. SUB, and ASCII. SUBC) return all digits in ASCII 
display format, that is, all byte values within the range hex 30 to hex 
39. 
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DATA REPRESENTATIONS 
Numeric String in Register 

x | d | x ; d ! x ! d ! x ] d |x ! d | x ! d ! x ! d |x ; d 



where 

x = hex3 or [= if all bits to left or right = 0] 
D = hexO through hex9 



15 
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4 INSTRUCTION SET COMPOSITION 

Instructions on the ELXSI machine operate on a large variety of data 
types using standard primitives and microcode optimizations. This 
chapter addresses those instructions that execute within a process. 
The message system instructions may be found in Chapter 14. 

Most instructions within a process are register directed with the 
design of minimizing accesses to memory. A fast addressing and 
execution schema results from a variable length instruction format and 
efficient operand addressing. Basically, the information within the 
first 3 nibbles specifies the instruction format, the addressing form, 
and the operation. The first pass at the instruction defines all 
operands, fetches the memory operand (if any), and hands the operation 
over to the appropriate hardware to execute. There are no memory 
indirect operations, and in general, no more than one memory reference, 
so only one memory cycle is used. 



4.1 INSTRUCTION TYPES 

There are two overall types of instructions on the ELXSI , generalized 
and non-generalized. Instructions that typically manipulate register 
data and require addressing flexibility fall into the generalized 
class. These include load, store, arithmetic, logical, and data 
conversion instructions. Instructions that do not need addressing 
flexibility or are highly specialized fall into the non-generalized 
class and include flow of control instructions, microcode optimized 
instructions, and instructions for inter-process communication. 
Non-generalized instructions minimize the overall instruction set 
complexity by eliminating unneeded addressing forms. 



4.2 ADDRESSING MODES 

Addressing modes allow the the user (compiler or human) to optimally 
address operands for the instruction. Non-memory operands include 
registers and immediate data. Memory operands may be addressed through 
register indirects (base and index) and immediate data, or various 
combinations thereof. 

Generalized instructions have 15 addressing modes; 5 of these belong 
to a subclass known as short-op addressing. The other ten, referred to 
as generalized addressing modes, enable a wide selection of addressing 
forms and are characterized by 12-bit opcode fields. A property of the 
generalized class of instructions is the singular correspondence 
between an addressing mode and the format and length of the 
instruction; both are determined from the first byte. 

Short-ops have single-byte opcodes and exist as optimizations of 
frequently used long-op (generalized) addressing forms. There are 5 
addressing modes, and there is usually a corresponding long-op 
instruction for each short-op form. 
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Non-generalized instructions nave addressing forms that are 
each instruction, and they have no fixed format. 



unique to 



The diagram below shows a typical form of a generalized class 
instruction with generalized addressing. The Instruction Specification 
Field (ISF) holds the opcode and the addressing mode. The target 
register field specifies the register to receive the results of a 
computation; this register may concurrently be a source. The 
addressing information area is of variable length and may contain 
register specifier fields for source operands, an address, or immediate 
encoded data. 



Typical Form of Instruction using Generalized Addressing 
1 2 3 4 5 6 7 8 9 10 11 12 13 nibble 
ISF j T ] addressing information \ 



i Target register field 

Instruction specification field 



The first 2 nibbles of the 
addressing class and the 
may be seen below: 



opcode are sufficient 
addressing mode, if any. 



Addressing class 

Generalized = 
Short-op = 
Non-generalized = 



Nibble is in set AND 

[3 4567BCDEF] AND 

[0 1 8 9 A] AND 

[ opcode ] AND 



to establish the 
This relationship 



Nibble 1 is 



[ non-zero ] 
[ non-zero ] 
[ zero ] 



Generalized instructions are always characterized with a non-zero value 
in nibble 1. When this is true, nibble establishes the addressing 
mode and, with the exception of appendages, the format and the length 
of the instruction. 
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The generalized addressing (long-opcode) form is shown below: 

ISF for Generalized Addressing Forms 
bit .0 3 4 7 8 11 

| Address mode J OP1 \ OP2 [ 



-> 
-> 



.A A. 



I I I 

I I I 

[34567BCDEF] non-zero opcode opcode 



The short-opcode addressing forms, belonging to the class of 
generalized instructions, use nibble 1 for the opcode and nibble for 
the addressing mode, as seen below: 



ISF for Short Opcode Addressing Forms 



it 


3 


4 7 


v 


i 


Address mode 


1 OP1 ; 


— / 

s 


A 


__ A 


A A 


/ 




1 
1 

[0 1 8 9 A] 


1 

non-zero opcode 





The non-generalized class of instructions are characterized by having a 
zero value in nibble 1. They do not have addressing modes, rather the 
addressing schema is specific to each instruction. Nibble zero is now 
part of the opcode. Its usual form may be seen below: 



ISF for Non-Generalized Instructions 
bit 3 4 7 8 11 

I OP0 I OP1 | OP2 



-> 

"> 



-A A. 



I I I 

opcode opcode = opcode (optional) 
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The remainder of these instructions hold register specifier fields, 
addressing information, immediate encoded values, and appendages as 
appropriate . 



4.3 REGISTER SPECIFIERS 

Register specifiers either point to register operands or hold immediate 
values as an operand. A register operand may be a register whose 
contents are to be used in, say, an arithmetic operation, or whose 
contents may point to a memory address. Register specifiers reside in 
one or more 4-bit fields of an instruction and have a numeric range of 
('0' to 'F') hex, representing the general purpose registers R0 to R15. 

For the generalized instructions, the inclusion of the 4-bit register 
specifier fields is specific to each addressing mode rather than to the 
instruction. Regardless of whether the register is operative in a 
given instruction, the field must be included if it is specified in 
that addressing mode. This is because instructions have a fixed length 
characteristic of each addressing mode. For example, instructions that 
have monadic operations, such as logical NOT, may use only 2 operands, 
the target and source operand. Operand Ry, usually another source 
operand, is ignored, although its register specifier field is encoded 
in the instruction as a requisite of the addressing mode. 



Register Specifiers for Generalized Addressing Modes 
nibble 0123456789. 
| am ]OPl |OP2 ] Rx J Ry J Rz J 



> 
> • 



In Generalized Addressing modes, the nibbles labeled Rx, Ry and Rz may 
be used for register specifiers. Rx is usually the target operand, and 
in some cases may be both the source and target. 



Register Specifiers for Short-Op Addressing Modes 
nibble 12 3 

| am |0P1 I Rw I Rx ; 



In Short-Op addressing modes, the nibbles labeled Rw and Rx may be used 
for register specifiers. Rx is usually the target operand, and in some 
cases may be both source and target. 
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Register Specifiers for Non-Generalized Instructions 
nibble 0123456789 

|OP0 JOPl |0P2 j Rx | Ry J RZ | Rt J Rv J — | — ! 



-> 
-> 



For non-generalized instructions, no strict format is followed, and all 
labeled nibbles (Rx through Rv) may be used for register fields. 



4.4 DESCRIPTION AND USE OF ADDRESSING MODES 

This section describes each addressing mode with the memory layout and 
the assembler usage. The diagrams show memory layouts of the 15 
generalized and short opcode addressing modes. The memory layouts of 
the non-generalized instructions are instruction-specific and are 
described with the instructions. Use of the given assembler syntax 
will force the specified addressing mode, rather than allowing the 
compiler to make the selection. 

The symbols have the following meanings: 

o A register specifier surrounded by brackets " []" indicates that 
the contents of the register point to a memory location. If 
these symbols are adjacent, then sum the register quantities to 
find an effective address. 

o A symbol having the form "e{}" indicates a displacement added to 
find an effective address. The number within the brackets 
indicates the bit length of the displacement quantity encoded in 
the instruction. 

o A symbol having the form "=e{}" indicates that the value encoded 
in the instruction is to be used as an immediate operand rather 
than for an address. 



Further descriptions may be found in Appendix E. 

The address space for a process in the ELXSI machine is 32 bits. All 
effective addresses are 32-bit signed integers, and all address 
calculations use signed arithmetic. If an operand or an address 
computation exceeds 32 bits in length (such as a base register) , the 
lower 32 bits are extracted without regard for the value of the unused 
high order bits. Overflow is ignored (and will not be detected). 
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There are no restrictions on register usage for establishing an 
effective address. Any register may be used for the base, index or 
displacement as the user may find appropriate. To find an effective 
address, simply add together the contents of the registers specified 
for the address computation along with any immediate values encoded in 
the instruction, as applicable to the addressing mode. 



Instructions start on any byte boundary and may cross 
boundaries. 



physical memory 



4.4.1 Mode 0: 1 Register, Register (Short) 
Assembler usage: op Rx,Rw 



] ! sh J Rw | Rx 



4.4.2 Mode 1: 1 Register, Register (Short) 
Assembler usage: op Rx,Rw 



J 1 J sh J Rw J Rx 



Modes and 1 are used when both operands reside in registers and the 
result may replace one of the operands. In general, Rx is both a 
source and a target, and Rw is a source. These are short opcode 
versions of mode 3. 



4.4.3 Mode 3: 2 Register, Register 
Assembler usage: op Rx,Ry,Rz 



long 



! Rx ] Ry ! Rz J 



Mode 3 is used when the source operands reside in registers and the 
target is a register. In general, Rx is the target and Ry and Rz are 
the sources. For monadic operations Ry is usually ignored. 
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4.4.4 Mode 4: 1 Register, Absolute Memory Address 
Assembler usage: op Rx,e{l6} 



[ 4 J long J Rx ] 16-bit vir-abs j 



Mode 4 uses an unsigned 16-bit integer as the virtual memory address of 
the data item, and is intended to provide access to global scalars 
residing in the first 64 Kbytes of the virtual memory space. This mode 
is an optimization of mode 6. 



4.4.5 Mode 5: 2 Register, Immediate 
Assembler usage: op Rx,Ry,=e{l2} 



1 c I 

I 



5 ] long | Rx | Ry J 12-bit immed ] 



Mode 5 is used when one of the source operands is immediate. The 
immediate operand is a 12-bit signed integer. This is an optimization 
of mode 7. Since most immediate values are small, this instruction 
will suffice in a majority of the cases. 



4.4.6 Mode 6: 2 Register, Long Absolute Memory Address 
Assembler usage: op Rx,Ry,e{32} 

I 6 J long ; Rx J Ry J \ 32-bit vir-abs 



Mode 6 uses a signed 32-bit integer as the virtual memory address of 
the data item, to provide access to global scalars residing anywhere in 
the virtual memory space. 



4.4.7 Mode 7: 2 Register, Long Immediate 
Assembler usage: op Rx,Ry,=e{32} 



! 7 J long | Rx | Ry [ ! 32-bit immed 



Mode 7 is used in place of the 2 Register, Immediate mode when the 
immediate operand cannot be held in a 12-bit signed integer. 
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4.4.8 Mode 8: Stack Pointer Relative (Short) 
Assembler usage: op Rx,[SP]e6 
where e = 4n, 0<=n<=15 



| 8 I sh | n I Ex ! 

4.4.9 Mode 9: Stack Pointer Relative (Short) 
Assembler usage: op Rx,[SP]e6 
where e = 4n, 0<=n<=15 



I 9 I sh J n I Rx i 



Modes 8 and 9 provide access to local variables. The effective address 
([sp] + 4*n) jumps in multiples of four bytes relative to the stack 
pointer. These modes are an optimization of modes D and F, and one of 
them must be used if either the data item does not start on a multiple 
of 4 bytes from the stack pointer, or the data item is out of range of 
these modes. 



4.4.10 Mode A: 1 Register, Base + Zero Displacement (Short) 
Assembler usage: op Rx,[Rw] 



A ! sh ! Rw ! Rx ! 



i a i 



Mode A is used to access based scalars (such as in the Pascal heap) , 
and to reference parameters. This mode is a short opcode optimization 
of mode B, and has only two operands. The effective address = [Rw] . 

4.4.11 Mode B: 2 Register, Base + Zero Displacement 
Assembler usage: op Rx,Ry,[Rz] 



B ! long | Rx J Ry | Rz 



Mode B is the generalized form of mode A, and is used in a similar 
fashion. This mode (and mode A) are sometimes referred to as "register 
indirect". The effective address = [Rz]. 
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4.4.12 Mode C: 1 Register, Base + Index + Zero Displacement 
Assembler usage: op Rx,[Ry][Rz] 



j C ; long | Rx | Ry ! Rz | 



Mode C is useful for access to elements of arrays passed as parameters 
to a subroutine. The effective address of the data item = [Ry][Rz], or 
the sum of the contents of Ry and Rz. 



4.4.13 Mode D: 1 Register, Base + 12-bit Displacement 
Assembler usage: op Rx r [Ry]e{l2} 



| D | long I Rx I Ry | 12-bit dspl J 



Mode D is a generalization of modes 8 and 9, and is used to access 
local scalars and records, or records in the heap. This mode is an 
optimization of mode F. The effective address of the data item = [Ry] 
+ the 12-bit signed displacement. 



4.4.14 Mode E: 1 Register, Base + Index + 32-bit Displacement 
Assembler usage: op Rx, [Ry] [Rz]e{32} 



j E I long I Rx i Ry ; Rz | 32-bit dspl ] 



Mode E is used for accessing arrays of records passed as parameters. 
The displacement is used to give access to the elements of the record. 
The effective address = [Ry][Rz] + 32-bit signed displacement. 



4.4.15 Mode F: 2 Register, Base + 32-bit Displacement 
Assembler usage: op Rx,Ry, [Rz]e{32] 



| F I long I Rx J Ry I Rz I 32-bit dspl J 



Mode F provides access to the entire virtual memory, relative to a base 
register, and is a generalization of modes 8, 9 and D. The 32-bit 
displacement is signed. It is used to access global arrays, and may be 
useful for access to mapped files. The effective address of the data 
item = [Rz] + 32-bit signed displacement. 
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4.5 IMPLEMENTATION EXAMPLES 

The Integer Multiply instructions are used to illustrate some 
addressing forms, register usage, and instruction encoding at the 
machine level. Detailed descriptions of each of the addressing modes 
are in the previous section. Descriptions for the symbols may be found 
in appendix F. 

















1 MUL.16 


MUL.32 


MUL.64 


Implementation 






OBx 


RX <- 


RX 


* 


Rw (short opcode) 






3B8 


RX <- 


Ry 


* 


Rz 


! 498 


4A8 


4B8 


RX <- 


Rx 


* 


e(l6} 






5B8 


RX <- 


Ry 


* 


=e{l2) 


! 698 


6A8 


6B8 


RX <- 


Ry 


* 


e{32} 






7B8 


Rx <- 


Ry 


* 


=e{32} 


! B98 


BA8 


BB8 


Rx <- 


Ry 


* 


[Rz] 


1 C98 


CA8 


CB8 


Rx <- 


Rx 


* 


[Ry][Rz] 


1 D98 


DA8 


DB8 


RX <- 


Rx 


* 


[Ry]e{l2> 


i E98 


EA8 


EB8 


Rx <- 


Rx 


* 


[Ry][Rz]e{32} 


! F98 


FA8 


FB8 


RX <- 


Ry 


* 


[Rz]e{32> 



Addressing mode 



Source Operands 



Target Operand 



The MUL instruction finds the product of the source operands and places 
the result into the register specified by Rx. The instruction may 
specify two operands or three operands. In 2 operand forms, found in 
addressing modes [0 4 C D E] , Rx is both the target and a source 
operand, and 'last operand' is the other source operand. In 3 operand 
forms, found in addressing modes [3 5 6 7 B F], Ry and 'last operand' 
are the source operands, and Rx is the target operand. 

Find the code EB8. Observe that this is a MUL.64 instruction of the 
generalized addressing type with addressing mode 'E' . The action, from 
the 'Implementation' column to the right, reads, 

"Multiply the contents of the register specified by Rx with the 
contents of the effective address, and place the result into the 
register specified by Rx". 

The effective address is the sum of registers Ry + Rz + the 32-bit 
signed integer displacement encoded in the instruction. The contents 
of the effective address is a 64-bit Integer (MUL.64) . 

Find the code EA8. Note that the addressing mode is the same. 
However, the contents of the effective address is now a 32-bit word 
(MUL.32). For this instruction, the 32-bit word is sign extended to 
64 bits prior to the multiply. 
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Find the code OBx. This is a MUL.64 instruction with a short opcode 
addressing format. '0' specifies the addressing mode, and 'x' 
indicates that the nibble belongs to the register specifier Rw. The 
action is 

"Multiply the contents of registers Rx and Rw, and place the result 
into register Rx" . 

Assume that we have a 16-bit local scalar that we wish to multiply 
against the contents of register Rll, with the result placed in Rll. 
We find that the MUL.16 instruction using addressing mode 'D', is 
appropriate. The opcode becomes 'D98'. Our base register, [Ry], is 
register R9. Assuming some quantities: 



base register = 0000000000100020 

16-bit scalar = 8000 

12-bit displacement = 032 

source/target Rll = 2000000000000000 



The effective address of the scalar is '100052' hex, or the sum of the 
base register and the 12-bit displacement. The instruction now takes 
the 16-bit scalar from this location and sign-extends it, as all 
integer operations are on 64-bit quantities. The 16-bit sign-extended 
scalar is now 



FFFFFFFFFFFF8000 



The sign-extended scalar is then multiplied with Rll. The instruction 
generates an INTEGER OVERFLOW exception if a carry is propagated out of 
the sign bit. This is the case here. The exception is trapped if the 
INTEGER OVERFLOW trap is enabled in the Process Status Word, otherwise 
the result is placed into Rll and the integer overflow is ignored. 

The MUL.16 instruction used in the previous example would be encoded as 
follows : 



D98B9032 

where D = addressing mode 

98 = opcode for MUL.16 

B = source/target register 

9 = base register 

032 = displacement 
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5 DATA TRANSFER INSTRUCTIONS 

The instructions described in this chapter are used to move data. 
These instructions are generally classified according to the data types 
that they operate on, as listed below. 

The monadic transfer instructions move data in byte- size quanta between 
registers, from a register to memory, or from memory to a register. 

Bit field insertion and extraction instructions allow the manipulation 
of data fields having variable length and placement within a register. 

Mutual exclusion instructions allow uninterruptable swaps between a 
register and memory. These are typically used to 'semaphore' between 
co-operating processes. 

The byte string copy instructions allow the movement of string type 
data. 



Monadic Transfer Instructions 

LD Load Register Sign Extended 

LDZ Load Register Zero Extended 

ST Store Register 

STI Store Immediate 

STIN Store Immediate Negated 

STV Store Register with Overflow Check 



Bit Field Insertion and Extraction 

INSERT Insert Bit Field 

EXTRACT Extract Bit Field, Sign Extended 

EXTRACTZ Extract Bit Field, Zero Extended 



Mutual Exclusion Instructions 

EXCH Exchange Register and Memory 

EXCH.AND 

EXCH. OR 



Byte String Copy Instructions 

COPYB Copy Byte String 

COPYB. CONST Copy Constant Byte String 
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5.1 MONADIC TRANSFER INSTRUCTIONS 

These instructions copy byte-oriented data between registers or between 
a register and memory. LDx instructions move data into a register 
specified by 0P1. STx instructions move data into a memory location 
specified by 'Last Operand 1 . Register to register loads for 
non-fullword operands and register to register stores are undefined. 



5.1.1 LD Load Register Sign Extended 

5.1.2 LDZ Load Register Zero Extended 

Copy 'Last Operand* into Operand 1, low order justified. Sign extend 
the result in the 64-bit destination operand for LD, and zero extend 
the result for LDZ. 















1 LD.8 


LD.16 


LD.32 


LD.64 


Implementation 








01X 


RX 


<- 


RW 








3B0 


RX 


<- 


RZ 


! 480 


490 


4A0 


4B0 


RX 


<- 


e{l6} 








5B0 


RX 


<" 


=e{l2} 


1 680 


690 


6A0 


6B0 


RX 


<- 


e{32} 






81X 




Rx 


<- 


[SP]e{6} 






AlX 




Rx 


<- 


[Rw] 


; B80 


B90 


BAO 


BBO 


Rx 


<- 


[Rz] 


| C80 


C90 


CAO 


CBO 


RX 


<" 


[Ry][Rz] 


•| D80 


D90 


DAO 


DBO 


RX 


<- 


[Ry]e{l2} 


| E80 


E90 


EAO 


EBO 


Rx 


<" 


[Ry][Rz]e{32} 


| F80 


F90. 


FAO 


FBO 


RX 


<" 


[Rz]e{32} 









Opcode 










!ldz.8 


LDZ. 16 


LDZ. 24 


LDZ. 32 


LDZ. 40 


LDZ. 48 


LDZ. 56 1 


Implementat i on 


1 481 


491 


4B1 


4A1 


497 


4A7 


4B7 | 


Rx <- e{l6> 


| 681 


691 


6B1 


6A1 


697 


6A7 


6B7 J 


Rx <- e(32> 


| 91x 














Rx <- [SP]e{6} 


! B81 


B91 


BB1 


BA1 


B97 


BA7 


BB7 J 


Rx <- [Rz] 


J C81 


C91 


CB1 


CA1 


C97 


CA7 


CB7 J 


Rx <- [Ry][Rz] 


| D81 


D91 


DB1 


DAI 


D97 


DA7 


db7 ; 


Rx <- [Ry]e(l2l 


J E81 


E91 


EB1 


EA1 


E97 


EA7 


eb7 ; 


Rx <- [Ry][Rz]e{32) 


1 F81 


F91 


FBI 


FA1 


F97 


FA7 


fb7 ; 


Rx <- [Rz]e{32} 



Instruction Specific Exceptions: none 
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5.1.3 ST Store Register 



Copy the rightmost (low order) bits of Operand 1 into 'Last 
Stores into registers are undefined for this instruction. 



Operand ' . 

























| ST. 8 


ST. 16 


ST. 24 


ST. 32 


ST. 40 


ST. 48 


ST. 56 


ST. 64; 


Implementat 


ion 




1 460 


461 


46C 


462 


46D 


46E 


46F 


463 ; 


e{l6} 




<- 


RX \ 


| 660 


661 


66C 


662 


66D 


66E 


66F 


663 J 


e{32} 




<- 


Rx J 


| 87x 






86x 
A7x 










[SP]e{6l 
[Rw] 




<- 
<- 


RX J 
RX J 


| B60 


B61 


B6C 


B62 


B6D 


B6E 


B6F 


B63 J 


[Rz] 




<- 


RX ; 


1 C60 


C61 


C6C 


C62 


C6D 


C6E 


C6F 


C63 j 


[Ry][Rz] 




<- 


Rx ! 


1 D60 


D61 


D6C 


D62 


D6D 


D6E 


D6F 


D63 | 


[Ry]e{l2} 




<- 


RX | 


| E60 


E61 


E6C 


E62 


E6D 


E6E 


E6F 


E63 | 


[Ry][Rz]e 


{32} 


<- 


RX J 


| F60 


F61 


F6C 


F62 


F6D 


F6E 


F6F 


F63 j 


[Rz]e{32} 




<- 


RX j 



Instruction Specific Exceptions: none 



5.1.4 STV Store Register with Overflow Check 

Copy the low order 8, 16, or 32 bits to 'Last Operand', and then check 
Operand 1 (Rx) for Integer Overflow. Overflow occurs if the upper 57, 
49, or 33 bits are not the same. For a discussion on exception 
handling, refer to Chapter 2, "Architecture". 





- Opcode - 






; STV. 8 


STV. 16 


STV. 32 


| Implementation 


j 464 


465 


466 


1 e{l6> <- Rx 


J 664 


665 


666 


! e{32} <- Rx 






96x 


\ [SP]e{6) <- Rx 






A6x 


! [Rw] <- Rx 


J B64 


B65 


B66 


! [Rz] <- Rx 


! C64 


C65 


C66 


1 [Ry][Rz] <- Rx 


J D64 


D65 


D66 


i [Ry]e{l2] <- Rx 


i E64 


E65 


E66 


! [Ry][Rz]e{32> <- Rx 


| F64 


F65 


F66 


j [Rz]e{32> <- Rx 



Instruction Specific Exceptions: 



INTEGER OVERFLOW 



DATA TRANSFER INSTRUCTIONS 



5.1.5 STI Store Immediate 

Store the value of the unsigned 4-bit Rx field into the 'Last Operand', 
and zero extend to the appropriate size. A STORE IMMEDIATE of has 
the effect of a CLEAR instruction. The range for Operand 1 is (0 to 
15). 















STI. 8 


STI. 16 


STI. 32 


STI . 64 


Implementation 












05X 


Rw <- 


=Rx 


(0..15) 








353 


Rz <- 


=Rx 


(0..15) 


450 


451 


452 


453 


e{l6} <- 


=Rx 


(0..15) 


650 


651 


652 


653 


e{32} <- 


=Rx 


(0..15) 






85x 




[SP]e{6) <- 


=RX 


(0..15) 


B50 


B51 


B52 


B53 


[Rz] <- 


=Rx 


(0..15) 


C50 


C51 


C52 


C53 


[RyKRz] <- 


=Rx 


(0..15) 


D50 


D51 


D52 


D53 


[Ry]e{l2} <- 


=Rx 


(0..15) 


E50 


E51 


E52 


E53 


[Ry][Rz]e{32} <- 


=RX 


(0..15) 


F50 


F51 


F52 


F53 


[Rz]e{32} <- 


=Rx 


(0..15) 



Instruction Specific Exceptions: none 



5.1.6 STIN Store Immediate Negated 



Zero extend and then form the l's complement of the unsigned 4-bit Rx 
field, storing the result into 'Last Operand'. The range for immediate 
operands is (-16 to -1), as the one's complement biases the value of 
the 4-bit operand by -1. 















STIN. 8 


STIN. 


16 


STIN. 32 


STIN. 64; 


Implementation 














15X ; 


Rw <- 


1' s cp 


=RX 










357 i 


Rz <- 


1' s cp 


=RX 


454 


455 




456 


457 ! 


e{l6} <- 


1' s cp 


=RX 


654 


655 




656 


657 | 


e{32} <- 


l's Cp 


=Rx 


B54 


B55 




B56 


B57 I 


[Rz] <- 


l' s cp 


=RX 


C54 


C55 




C56 


C57 J 


[Ry] [Rz] <- 


l's cp 


=RX 


D54 


D55 




D56 


D57 \ 


[Ry]e(l2} <- 


l's cp 


=RX 


E54 


E55 




E56 


E57 1 


[Ry][Rz]e{32> <- 


l's cp 


=RX 


F54 


F55 




F56 


F57 \ 


[Rz]e{32} <- 


l's cp 


=Rx 



Instruction Specific Exceptions: none 
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5.2 INSERT AND EXTRACT BIT FIELD OPERATIONS 

These instructions move bit fields into or out of registers. The 
length and starting location of the bit fields are specified in the 
appendage of the instruction. 



5.2.1 EXTRACT 

5.2.2 EXTRACTZ 



Extract Bit Field, Sign Extended 
Extract Bit Field, Zero Extended 



Extract a bit field from register Rz and store right justified into 
register Rx. SIGN extend the result for EXTRACT and ZERO extend for 
EXTRACTZ. The appendage holds a start bit pointer and a length value 
for the desired extract. The start bit is the leftmost or sign bit 
position of the bit field, and the length value is 64 minus the bit 
field length. The range for the start value is to 63. The range for 
the length value is 1 to 64. The sum of the start bit and the field 
width must be less than or equal to 64; otherwise, results will be 
undefined, and implementation dependent side effects will occur. 



Opcode assignment | Code 



Implementation 



EXTRACT 
EXTRACTZ 



D06 j Rx <- Rz:<st:len>, sign extended 
D07 | Rx <- Rz:<st:len>, zero extended 



| D | ! 6 ! x ! ! z ! appendage | EXTRACT 



{D|o|7jxJo|z| appendage 



EXTRACTZ 



Source register Rz 



Result register Rx 



Opcode 



DATA TRANSFER INSTRUCTIONS 



The appendage has the following formats 



J ! J Start bit pos (0-63) | j | 64 - bit field length | 



bit 



9 10 11 12 13 14 15 



There is no data checking of appendages or operands with these 
instructions. Use with caution. 



Instruction Specific Exceptions: None 



5.2.3 INSERT Insert Bit Field Operation 

INSERT takes a right justified bit field from register Rz r displaces it 
leftward, overlays it onto an image of Ry, and places the result into 
Rx. The appendage specifies the length of the field and the starting 
bit position for the overlay. Values in Ry and Rz are unchanged. 



A bit field length of zero is allowed as a NULL case. Use a LD.64 
instruction for bit field lengths of 64. High order bits of Rz not in 
the bit field to be inserted MUST be zero (observe the effect of signed 
integers in this register) . The sum of the start bit and the field 
width must be less than or equal to 64; otherwise, results will be 
undefined, and implementation dependent side effects will occur. 



DATA TRANSFER INSTRUCTIONS 



| Opcode assignment J Code 



Implementation 

Rx <- Rz inserted into Ry 



INSERT 



D05 



The format of the instruction is 



D ! 



appendage 



Opcode 



Source register 



Source register 



Result register 



The appendage has the following format: 



bit 



I ; I Start bit pos (0-63) I i ibit field length 0-63 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 



Typically, these instructions are used to manipulate packed records. 
Observe the asymmetry of the INSERT and EXTRACT instructions, as INSERT 
does not check overflow. Also observe the differences in the 
appendages, keeping in mind that there is no data checking of 
appendages or operands with these instructions. 



Instruction Specific Exceptions: none 



5.3 MUTUAL EXCLUSION INSTRUCTIONS 



Mutual Exclusion instructions perform logically selective and 
uninterruptable register-memory swaps. The instructions are valid only 
on word-aligned, full 64-bit words, that is, the lower 3 bits of the 
target address must be zero. The operations work on both cacheable and 
non-cacheable memory operands. In both cases, the execution of the 
instruction is 'atomic', i.e., the read modify write sequence is 
indivisible with respect to any other process. If the target is in 
cache, then only the cache (and not memory) is modified. 



DATA TRANSFER INSTRUCTIONS 



These instructions generally have two types of applications; in the 
first case to semaphore between processes using a non-cacheable data 
item as a target, and in the second case to enable a process to 
coordinate with itself. Using cacheable data items to semaphore 
between processes is NOT recommended because of critical section 
problems (one process may access the datum in cache while another 
process accesses the datum with the same address in memory) . 

The EXCH operation exchanges Rx with the memory operand pointed to by 
Rz- For the logical variants, the instruction performs a logical <op> 
between Rx and the 64-bit memory operand, places the result in Rx, and 
then EXCHanges Rx with memory. The memory location is specified by a 
base register. 



5.3.1 EXCH Exchange Register and Memory 

5.3.2 EXCH. AND 

5.3.3 EXCH. OR 



Opcode assignment , Code 



Implementation 



EXCH 
EXCH. AND 
EXCH. OR 



702 
703 
704 



[Rz] <-> RX 

[Rz] <-> RX < Rx AND [Rz] > 

[Rz] <-> RX < Rx OR [Rz] > 



The format of these non-generalized instructions is 



x 



EXCH instruction 



EXCH. AND instruction 



EXCH. OR instruction 



Opcode 



Base register Rz 



Register Rx 



Instruction specific exceptions: none 



DATA TRANSFER INSTRUCTIONS 



5.4 BYTE STRING COPY INSTRUCTIONS 

Byte string copy instructions perform memory-to-memory copies of 
strings (COPYB) , or repeatedly copy fullword constants into a string 
(COPYB. CONST) . 



5.4.1 COPYB Copy Byte String 

Copy the source string into the destination string. Rx contains the 
address of the destination string, Ry contains the address of the 
source string, and Rz contains the length of the source and destination 
strings which are of equal length. The instruction appears to move the 
string into a temporary location and then to the destination, such that 
it cannot be used to propagate a fill character through string 
overlapping. 



] Opcode assignment [ Code ] Implementation ] 

| COPYB I 706 | [Rx]:<st> <- [Ry]:<st>, Rz:<len> j 



The format of this non-generalized instruction is 



! 7 | | 6 ! x | y ! z I COPYB instruction 



Rz contains length of strings 



Ry contains address of source string 



Rx contains address of destination string 



Opcode 



Instruction Specific Exceptions: none 



Special notes: 

The contents of Rx, Ry, and Rz are undefined after execution of this 
instruction. 

Negative string lengths are treated as if the string has zero length 
and no data movement takes place. To generate an exception on negative 
string lengths, use a compare and generate exception instruction. 



DATA TRANSFER INSTRUCTIONS 



5.4.2 COPYB. CONST Copy Constant Byte String 

Rx contains the address of the destination string, Ry contains an 
8-byte source word, and Rz contains the length of the destination 
string. The instruction appears to perform a word-wise copy into 
successive destination string words, with the first byte of the source 
word overlaying the first byte of the destination, until [Rz] bytes 
have been copied. The length of the destination string need not be a 
multiple of 8 bytes. 



! Opcode assignment ] Code 



Implementation 

[Rx]:<st> <- Ry, Rz:<len> 



COPYB. CONST 



707 



The format of this non-generalized instruction is 



I? !o;7|x!y;z| 



COPYB. CONST instruction 



Rz contains length of destination 



Ry contains word constant 



Rx contains address of destination string 



Opcode 



Instruction specific exceptions: none 

Special notes: 

The contents of Rx and Rz are undefined after execution of this 
instruction. 



- 10 
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6 INTEGER INSTRUCTIONS 

Integer instructions may use 16-bit, 32-bit, or 64-bit source operands 
to perform 64-bit register arithmetic. Operands less than 64 bits, as 
specified in the instruction, are first sign extended prior to the 
operation. The ADD. 16 instruction, for example, sign extends the 
16-bit source operand to 64 bits and then performs the ADD with 64-bit 
precision. As such, INTEGER OVERFLOW exceptions are only generated 
from 64-bit overflows. The overflow is checked in Operand 1 after the 
result has been placed into the target operand. The MUL.128 and 
MULU.128 instructions are special cases, operating on 64-bit quantities 
and returning 128-bit results spanning 2 registers. 

To check for overflow in operands less than 64 bits, use a STORE WITH 
OVERFLOW CHECK instruction with the appropriate modulus. This will 
generate the exception if the source operand exceeds the size of the 
target operand. 



Integer Instructions 



ADD 

ADDUC 

ADD I 

DIV 

DIVR 

MUL 

MUL 

MULU 

NEG 

REM 

REHR 

SUB 

SUBR 

SUBUC 

SUBUCR 

SUB I 



Integer Addition 

Unsigned Integer Addition Generate Carry 

Integer Addition with Immediate Operand 

Integer Division 

Reverse Integer Division 

Integer Multiply 

128-Bit Integer Multiply 

128-Bit Unsigned Integer Multiply 

Integer Negate 

Remainder of Integer Divide 

Remainder of Reverse Integer Divide 

Integer Subtract 

Reverse Integer Subtraction 

Unsigned Integer Subtract Gen Carry 

Reverse Unsigned Int Sub Gen Carry 

Integer Subtraction with Immediate 



Arithmetic Shift Instructions 



SLA 
SRA 



Shift Left Arithmetic 
Shift Right Arithmetic 



INTEGER INSTRUCTIONS 



6.1 MULTIPLE PRECISION INTEGER ARITHMETIC 

Normal 64-bit or less arithmetic operations on the ELXSI are simply 
special cases of multiple precision arithmetic. This is an artifact of 
the ELXSI carry mechanism and two generic types of instructions; those 
that operate on unsigned integers and allow carry-out, and those that 
operate on signed integers and detect overflow. Unsigned integer 
addition will set the carry bit in the PSW in the event of a carry-out, 
and otherwise will clear it. Signed integer addition will set the 
INTEGER OVERFLOW exception in the event of a carry out, and will 
unconditionally clear the carry bit. 

Subtraction is one's complement addition where the subtrahend is 
complemented and added to the minuend along with the complement of the 
carry bit. A carry out in unsigned subtraction will clear the carry 
bit. In this way, the carry may be propagated as the carry bit will 
again be complemented when added into the next stage. With respect to 
a carry out, signed subtraction will perform the same action as signed 
addition. 

The user may check the state of the carry bit by retrieving the Process 
Status Word (READ. STAT) or alternatively, by executing the instruction 
SUB. 64 Rn,Rn. If the carry bit was set, the result is -1, otherwise 
the result is 0. This is illustrated below with the carry bit set: 

10110011 Rn 
+ 01001100 complement of Rn 
+ complement of carry bit in PSW 

11111111 

Use of the SUB. 64 instruction will always clear the carry bit. The 
above example will also set the INTEGER OVERFLOW exception if the carry 
bit tested was clear. If the SUBUC.64 instruction was used instead, 
the effect would be to toggle the carry bit in the PSW. 

In the context of multiple precision arithmetic, the lower stages of 
the problem would first be computed using the unsigned integer 
instructions. In this way, a carry may be propagated to the next 
stage. When the high order stage is reached, the signed integer 
instructions are used to clear the carry bit and to detect overflow. 



INTEGER INSTRUCTIONS 



An example follows for chained subtraction: 

minuend = 0000112222222222 2222222222222222 
subtrahend = 0000000000000000 3222222222222222 

R0 = low order word of minuend 
Rl = high order word of minuend 
R2 = low order word of subtrahend 
R3 = high order word of subtrahend 

Carry bit in PSW = 

The first step is to use unsigned subtraction on the low order words of 
the subtrahend and minuend. The SUBUC.64 instruction using mode 3 is 
suitable for this. Making these assignments: 

Rx = target = R4 

Ry = low order word of minuend = R0 

Rz = low order word of subtrahend = R2 

The instruction is encoded as 31A402 

The result in R4 after execution is F000000000000000 with no carry. 

The absence of a carry out sets the carry bit in the PSW. The next 
step is to subtract the high order words as signed integers using the 
SUB. 64 instruction. This is to enable the detection of overflow. 
Using addressing mode 3 and making these assignments: 

Rx = target = R5 

Ry = high order word of minuend = Rl 

Rz = high order word of subtrahend = R3 

The instruction is encoded as 3BA513 

When this instruction is executed, it checks to see if a carry was 
generated by the previous stage and performs the following: 

0000112222222222 - Rl 
+ FFFFFFFFFFFFFFFF = R3 complemented 



0000112222222221 
+ o (no carry in) 



0000112222222221 = high order result in R5 
The final result, concatenating R5 and R4, is 
0000112222222221 F00O00OOO0O0OOO0 



INTEGER INSTRUCTIONS 



At this point, the carry bit cleared in the PSW, as the SUB. 64 
instruction clears the carry. Integer overflow is not generated as the 
carry did not propagate to the sign bit. 



6.2 INTEGER ADDITION 

Add the source operands with the carry bit, place the result into 
Operand 1, and then check for overflow. In the 2 operand forms. 
Operand 1 is replaced by the sum of Operand 1 and Operand 2. In the 3 
operand forms, Operand 1 is replaced by the sum of Operand 2 and 
Operand 3. 

The carry bit is unconditionally cleared for ADD instructions, but set 
for ADDUC only if a 'l 1 is carried out of bit '0'. Operands are 
unsigned for ADDUC; signed integer operations may give unexpected 
results if the carry bit is set. 



6.2.1 ADD Integer Addition 

6.2.2 ADDUC Unsigned Integer Addition Generate Carry 





Opcode 














1 ADD. 16 


ADD. 32 


ADD. 64 


ADDUC. 64 


Implementation 










OBX 




Rx <- 


RX+RW 


+ 


carry 






3B9 


319 


Rx <- 


Ry+Rz 


+ 


carry 


! 499 


4A9 


4B9 


419 


Rx <- 


Rx+e {16} 


+ 


carry 






5B9 


519 


Rx <- 


Ry+=e {12} 


+ 


carry 


! 699 


6A9 


6B9 


619 


Rx <- 


Ry+e(32} 


+ 


carry 






7B9 


719 


Rx <- 


Ry+=e {32} 


+ 


carry 




89X 






Rx <- 


Rx+[SP]e{6} 


+ 


carry 




A9x 






Rx <- 


Rx+[Rw] 


+ 


carry 


j B99 


BA9 


BB9 


B19 


Rx <- 


Ry+[Rz] 


+ 


carry 


J C99 


CA9 


CB9 


C19 


Rx <- 


Rx+[Ry][Rz] 


+ 


carry 


\ D99 


DA9 


DB9 


D19 


RX <- 


Rx+[Ry]e{l2} 


+ 


carry 


J E99 


EA9 


EB9 


E19 


RX <- 


Rx+[Ry][Rz]e{32} 


+ 


carry 


| F99 


FA9 


FB9 


F19 


RX <- 


Ry+[Rz]e{32} 


+ 


carry 



Instruction Specific Exceptions, ADD: 

ADDUC: 



INTEGER OVERFLOW 
none 



6.2.3 ADDI Integer Addition with Immediate Operand 

Sum Rw with the immediate value in the four bit Rx specification field, 
place the result into Rw, clear the carry bit, and then check for 
integer overflow. The range of Rx is to 15. 



6 
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ADDI has the effect of an INCREMENT instruction if in the form 
ADDI. 64 l,Rw. There is no direct analogue for this instruction in 
the generalized addressing modes, although an ADD. 64 with modes 5 or 7 
could be used. 



Opcode - 
ADDI . 64 



Implementation 



04x 



Rw <- Rw + =Rx 



Instruction Specific Exceptions: 



INTEGER OVERFLOW 



6.3 INTEGER DIVISION 

Divide the source operands, place the result into Operand 1, and then 
check for integer overflow. DIV and DIVR perform identically with the 
exception of the source operand division order. In the 2 operand 
forms. Operand 1 is replaced by Operand 1 divided by Operand 2 (Operand 
2 divided by Operand 1 for DIVR). In the 3 operand forms, Operand 1 is 
replaced by Operand 2 divided by Operand 3 (Operand 3 divided by 
Operand 2 for DIVR) . 



6.3.1 DIV Integer Division 

6.3.2 DIVR Reverse Integer Division 











1 DIV. 16 


DIV. 32 


DIV. 64 


Implementation 






3BC 


Rx <- Ry/Rz 


! 49C 


4AC 


4BC 


Rx <- Ry/e{l6} 






5BC 


Rx <- Ry/=e{l2} 


| 69C 


6AC 


6BC 


Rx <- Ry/e{32} 






7BC 


Rx <- Ry/=e{32l 


| BCC 


BAC 


BBC 


Rx <- Ry/[Rz] 


! C9C 


CAC 


CBC 


Rx <- Rx/[Ry][Rz] 


i D9C 


DAC 


DBC 


Rx <- Rx/[Ry]e{l2} 


J E9C 


EAC 


EBC 


Rx <- Rx/[Ry][Rz]e{32} 


| F9C 


FAC 


FBC 


Rx <- Ry/[Rz]e{32} 



INTEGER INSTRUCTIONS 













] DIVR.16 


DIVR.32 


DIVR.64 | 


Implementation 




[ 49D 


4AD 


4bd ; 

5BD | 


Rx <- e{l6>/Ry 
Rx <- =e{l2}/Ry 




! 69D 


6AD 


6BD [ 
7BD J 


Rx <- e{32}/Ry 
Rx <- =e{32}/Ry 




J B9D 


BAD 


BBD I 


Rx <- [Rz]/Ry 




! C9D 


CAD 


CBD j 


Rx <- [Ry][Rz]/Rx 




! D9D 


DAD 


DBD \ 


Rx <- [Ry]e{l2>/Rx 




1 E9D 


EAD 


EBD j 


Rx <- [Ry][Rz]e{32}/Rx 




! F9D 


FAD 


FBD ' 


Rx <- [Rz]e{32}/Ry 





Instruction Specific Exceptions: 



INTEGER OVERFLOW 
INTEGER ZERO DIVIDE 



6.4 INTEGER MULTIPLY OPERATIONS 

Multiply the source operands, place the result into Operand 1, and then 
check for integer overflow. In the 2 operand forms, Operand 1 is 
replaced by Operand 1 multiplied by Operand 2. In the 3 operand forms, 
Operand 1 is replaced by Operand 2 multiplied by Operand 3. 



For MUL.128 and MULU.128, multiply the 64-bit source operands in Ry and 
Rz, with the 128-bit result replacing Rx and Rx+i. Rx receives the 
high order 64 bits of the result, and Rx+1 receives the low order 
64 bits. MUL.128 assumes signed integer operands, MULU.128 assumes 
unsigned integer operands. 



INTEGER INSTRUCTIONS 



6.4.1 MUL Integer Multiply 

6.4.2 MUL. 128 128-Bit Integer Multiply 

6.4.3 MULU.128 128-Bit Unsigned Integer Multiply 





- Opcode — 








MUL. 16 


MUL. 32 


MUL. 64 


Implementation 






OBx 


Rx <- Rx * 


Rw 






3B8 


Rx <- Ry * 


Rz 


498 


4A8 


4B8 


Rx <- Rx * 


e{l6> 






5B8 


Rx <- Ry * 


=e{l2} 


698 


6A8 


6B8 


Rx <- Ry * 


e{32) 






7B8 


Rx <- Ry * 


=e{32} 


B98 


BA8 


BB8 


Rx Kr Ry * 


[Rz] 


C98 


CA8 


CB8 


Rx <- Rx * 


[Ry][Rz] 


D98 


DA8 


DB8 


RX <- Rx * 


[Ry]e{l2> 


E98 


EA8 


EB8 


Rx <- Rx * 


[Ry][Rz]e{32} 


F98 


FA8 


FB8 


Rx <- Ry * 


[Rz]e{32} 



Opcode assignment , Code 



i 



Implementation 



MUL. 128 
MULU.128 



B02 ; 

B03 ! 



Rx,Rx+l <- Ry * RZ 
Rx,Rx+l <- Ry * Rz 



INTEGER INSTRUCTIONS 



The formats of the non-generalized instructions are 



! | |4 |x|y ! z I 



MUL.128 instruction 



; 



5 | x i y | z 



MULU.128 instruction 



Opcode 



Rz is source operand 



Ry is source operand 



Rx,Rx+i are the target operands 



Instruction Specific Exceptions, MUL: 

MUL.128: 
MULU.128: 



INTEGER OVERFLOW 

none 

none 



6.5 NEG INTEGER NEGATE 



Replace Operand 1 with the two's complement of 'Last Operand', and then 



check, for integer overflow, 
unmodified by this instruction. 



The carry bit is unreferenced and 





- Opcode — 






NEG. 16 


NEG. 32 


NEG. 64 1 


Implementation 






3B2 ; 


Rx <- two ' s cp of Rz 


492 


4A2 


4B2 | 


Rx <- two ' s cp of e {16} 


692 


6A2 




Rx <- two's cp of e{32} 


B92 


BA2 




Rx <- two's cp of [Rz] 


C92 


CA2 


CB2 | 


Rx <- two's cp of [Ry][Rz] 


D92 


DA2 


DB2 J 


Rx <- two's cp of [Ry]e{l2} 


E92 


EA2 


EB2 J 


Rx <- two's cp of [Ry][Rz]e{32) 


F92 


FA2 


i 


Rx <- two's cp of [Rz]e{32} 



Instruction Specific Exceptions: 



INTEGER OVERFLOW 



INTEGER INSTRUCTIONS 



6.6 REMAINDER OF INTEGER DIVIDE OPERATIONS 

Divide the source operands and place the remainder into Operand 1. REM 
and REMR perform identically with the exception of the order of source 
operand division. In the 2 operand form. Operand 1 is replaced with 
the remainder of Operand 1 divided by Operand 2 (Operand 2 divided by 
Operand 1 for REMR) . In the 3 operand form, Operand 1 is replaced with 
the remainder of Operand 2 divided by Operand 3 (Operand 3 divided by 
Operand 2 for REMR) . 

The quotient is rounded towards zero, and the dividend and remainder 
have the same sign if both are non-zero. This is the FORTRAN 
remainder. 



6.6.1 REM Remainder of Integer Divide 

6.6.2 REMR Remainder of Reverse Integer Divide 





- Opcode — 






| REM. 16 


REM. 32 


REM. 64 


Implementation 






3BE 


Rx <- rem of Ry/Rz 


1 49E 


4AE 


4BE 


Rx <- rem of Rx/e{l6} 






5BE 


Rx <- rem of Ry/=e(l2} 


\ 69E 


6AE 


6BE 


Rx <- rem of Ry/e{32> 






7BE 


Rx <- rem of Ry/=e{32} 


\ B9E 


BAE 


BBE 


Rx <- rem of Ry/[Rz] 


; C9E 


CAE 


CBE 


Rx <- rem of Rx/[Ry][Rz] 


; D9E 


DAE 


DBE 


Rx <- rem of Rx/[Ry]e{l2} 


j E9E 


EAE 


EBE 


Rx <- rem of Rx/[Ry][Rz]e{32} 


j F9E 


FAE 


FBE 


Rx <- rem of Ry/[Rz]e{32} 











j REMR. 16 


REMR. 32 


REMR. 64 1 


Implementation 


| 49F 


4AF 


4bf ; 


Rx <- rem of e{l6}/Rx 






5BF \ 


Rx <- rem of =e{l2}/Ry 


J 69F 


6AF 


6bf ; 


Rx <- rem of e{32}/Ry 






7BF ; 


Rx <- rem of =e{32}/Ry 


J B9F 


BAF 


BBF J 


Rx <- rem of [Rz]/Ry 


; C9F 


CAF 


CBF \ 


Rx <- rem of [Ry][Rz]/Rx 


\ D9F 


DAF 


DBF \ 


Rx <- rem of [Ry]e{l2}/Rx 


\ E9F 


EAF 


EBF \ 


Rx <- rem of [Ry] [Rz]e{32}/Rx 


! F9F 


FAF 


FBF ; 


Rx <- rem of [Rz]e{32}/Ry 



Instruction Specific Exceptions: 



INTEGER ZERO DIVIDE 



9 



INTEGER INSTRUCTIONS 



6.7 INTEGER SUBTRACT OPERATIONS 

Replace Operand 1 with the difference of the source operands, and then 
check, for integer overflow. SUB and SUBR behave identically with 
exception of the order of source operand subtraction. In 2 operand 
forms, replace Operand 1 with Operand 1 minus Operand 2 (Operand 2 
minus Operand 1 for SUBR) . In 3 operand forms , replace Operand 1 with 
Operand 2 minus Operand 3 (Operand 3 minus Operand 2 for SUBR) . The 
carry bit is cleared with these instructions. 



6.7.1 SUB Integer Subtract 

6.7.2 SUBR Reverse Integer Subtract 

















! SUB. 16 


SUB. 32 


SUB. 64 




Implementation 








OAX 


RX 


<- 


RX-RW 


- carry 






3BA 


Rx 


<- 


Ry-Rz 


- carry 


I 49A 


4AA 


4BA 


RX 


<- 


Ry-e {16} 


- carry 






5BA 


Rx 


<- 


Ry-=e {12} 


- carry 


! 69A 


6AA 


6BA 


Rx 


<- 


Ry-e {32} 


- carry 






7BA 


Rx 


<- 


Ry-=e{32} 


- carry 




8AX 




Rx 


<- 


Rx-[SP]e{6> 


- carry 




AAX 




RX 


<- 


Rx-[Rw] 


- carry 


! B9A 


BAA 


BBA 


Rx 


<- 


Ry-[Rz] 


- carry 


J C9A 


CAA 


CBA 


RX 


<- 


Rx-[Ry][Rz] 


- carry 


\ D9A 


DAA 


DBA 


RX 


<- 


Rx-[Ry]e{l2} 


- carry 


j E9A 


EAA 


EBA 


Rx 


<- 


Rx-[Ry][Rz]e{32} 


- carry 


1 F9A 


FAA 


FBA 


Rx 


<- 


Ry-[Rz]e{32} 


- carry 
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INTEGER INSTRUCTIONS 





- Opcode — 














| SUBR.16 


SUBR.32 


SUBR.64 


Implementation 










OBX 


Rx 


<- 


Rw-Rx 


- 


carry 


i 49B 


4AB 


4BB 


Rx 


<- 


e {16} -Rx 


- 


carry 






5BB 


Rx 


<" 


=e{l2}-Ry 


- 


carry 


| 69B 


6AB 


6BB 


Rx 


<- 


e{32}-Ry 


- 


carry 






7BB 


Rx 


<- 


=e{32}-Ry 


- 


carry 




8Bx 




Rx 


<" 


[SP]e{6}-Rx 


- 


carry 




ABx 




Rx 


<- 


[Rw]-Rx 


- 


carry 


! B9B 


BAB 


BBB 


Rx 


<- 


[Rz]-Ry 


- 


carry 


! C9B 


CAB 


CBB 


Rx 


<- 


[Ry][Rz]-Rx 


- 


carry 


! D9B 


DAB 


DBB 


Rx 


<" 


[Ry]e{l2}-Rx 


- 


carry 


! E9B 


EAB 


EBB 


Rx 


<- 


[Ry][Rz]e{32}-Rx 


- 


carry 


| F9B 


FAB 


FBB 


Rx 


<- 


[Rz]e{32}-Ry 


- 


carry 



Instruction Specific Exceptions: 



INTEGER OVERFLOW 



6.7.3 SUBUC 

6.7.4 SUBUCR 



Unsigned Integer Subtract Gen Carry 
Reverse Unsigned Integer Subtract Gen Carry 



Replace Operand 1 with the difference of the unsigned source operands. 
SUBUC and SUBUCR behave identically except for the order of source 
operand subtraction. In 2 operand forms, replace Operand 1 with 
Operand 1 minus Operand 2 (Operand 2 minus Operand 1 for SUBUCR) . In 3 
operand forms, replace Operand 1 with Operand 2 minus Operand 3 
(Operand 3 minus Operand 2 for SUBUCR) . A carry-out clears the carry 
bit, otherwise it is set. 









1 SUBUC. 64 


Implementation 




1 31A 


Rx <- Ry-Rz 


- carry 


j 41A 


Rx <- Rx-e{l6) 


- carry 


! 51A 


Rx <- Ry-=e{l2> 


- carry 


! 61A 


Rx <- Ry-e{32} 


- carry 


! 71A 


Rx <- Ry-=e{32} 


- carry 


I B1A 


Rx <- Ry-[Rz] 


- carry 


\ CIA 


Rx <- Rx-[Ry][Rz] 


- carry 


1 D1A 


Rx <- Rx-[Ry]e{l2} 


- carry 


| E1A 


Rx <- Rx-[Ry][Rz]e{32> 


- carry 


1 F1A 


Rx <- Ry-[Rz]e{32} 


- carry 
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INTEGER INSTRUCTIONS 



SUBUCR.64 


[ Implementation 




41B 


1 Rx <- e{l6}-Rx 


- carry 


51B 


! Rx <- =e{l2}-Ry 


- carry 


61B 


J Rx <- e{32}-Ry 


- carry 


71B 


1 Rx <- =e{32}-Ry 


- carry 


BIB 


I Rx <- [Rz]-Ry 


- carry 


C1B 


! Rx <- [Ry][Rz]-Rx 


- carry 


DIB 


! Rx <- [Ry]e{l2>-Rx 


- carry 


E1B 


! Rx <- [Ry][Rz]e{32}-Rx 


- carry 


FIB 


! Rx <- [Rz]e(32}-Ry 


- carry 



Instruction Specific Exceptions: none 



6.7.5 SUBI Integer Subtraction with Immediate Operand 

Subtract from Rw the immediate value plus one in the four bit Rx 
specification field, then place the result in Rw and clear the carry 
bit. When this operation is completed, check for integer overflow. 
The range of the effective operand is -16 to -1. 

SUBI has the effect of a DECREMENT instruction if in the form 
SUBI. 64 Rw,=l. There is no analogue in the generalized addressing 
modes for this instruction. 



- Opcode 
SUBI. 64 



Implementation 
Rw <- Rw - (=Rx+l) 



14x 



Instruction Specific Exceptions: 



INTEGER OVERFLOW 



6.8 ARITHMETIC SHIFT INSTRUCTIONS 



Arithmetic shift operations operate on 64-bit signed 
shift distances are unsigned integers modulo 64. 



integers. All 



In two operand forms, Operand 1 is replaced by the value of Operand 1 

shifted by Operand 2. In three operand forms, Operand 1 is replaced by 

the value of Operand 2 shifted by Operand 3. The fill bit is zero for 

SLA, and is the sign bit in the operand to be shifted for SLR. 
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INTEGER INSTRUCTIONS 



6.8.1 SLA Shift Left Arithmetic 

6.8.2 SRA Shift Right Arithmetic 



Opcode 

] SLA ] Implementation ] 

| 312 I Rx <- Ry shifted left by Rz J 

| 512 ! Rx <- Ry shifted left by =e{l2> \ 

| 712 | Rx <- Ry shifted left by =e{32> J 

Opcode ; 

] SRA J Implementation J 

i 313 | Rx <- Ry shifted right by Rz J 

! 513 \ Rx <- Ry shifted rignt by =e{l2} \ 

\ 713 ; Rx <- Ry shifted right by =e{32} J 



Special Notes: 

Overflow operations may occur with SLA and is equivalent to overflow in 
integer multiply. Overflow is checked after the target operand is 
written with the result. The overflow exception is generated if the 
sign bit changes as a result of a shift. This allows multiplication by 
powers of two with the detection of overflow. Note that the Shift Left 
Logical instruction does not generate this exception. 

A shift right by n with the SRA instruction will perform a division by 
2**n on a positive number. However, a shift right by n on a negative 
number will result in a rounding toward negative infinity. Thus it is 
necessary to adjust the number prior to the shift. To correctly 
perform a fast division by two on a negative number, precede the shift 
by n with an ADD of (2**n)-l. 



Instruction Specific Exceptions, SLA: 

SRA: 



INTEGER OVERFLOW 
none 
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FLOATING POINT INSTRUCTIONS 



7 FLOATING POINT INSTRUCTIONS 

The floating point operations conform to the proposed IEEE Floating 
Point Standard. The three floating point formats provided are: single 
(32 bits), double (64 bits), and double extended (80 bits). Refer to 
Chapter 3, "Data Representations", for a description of the standard 
and the encodings for numbers and symbols. Refer to Section 2.2, 
"Process Status Word", for a discussion of exception handling. 



FLOATING POINT INSTRUCTIONS 



FADD 


Floating 


FDIV 


Floating 


FDIVR 


Floating 


FMUL 


Floating 


FREM 


Floating 


FSQR 


Floating 


FSUB 


Floating 


FSUBR 


Floating 



Point Addition 

Point Division 

Point Division Reversed 

Point Multiply 

Point Remainder 

Point Square Root 

Point Subtraction 

Point Subtraction Reversed 



7.1 FADD 



FLOATING POINT ADDITION 



Add the source operands and place into Operand 1. With the two address 
forms, operands 1 and 2 are the sources. With the three operand forms, 
operands 2 and 3 are the sources. The result matrix is shown on the 
following page. 



FLOATING POINT INSTRUCTIONS 













| FADD.32 


FADD.64 






Implementation 


1 19X 


1DX 


Rx 


<- 


Rx + Rw 


[ 3C9 


3D9 


Rx 


<- 


Ry + Rz 


J 4C9 


4D9 


Rx 


<- 


Rx + e{l6} 


; 6C9 


6D9 


Rx 


<- 


Ry + e{32} 


j 7C9 




Rx 


<- 


Ry + =e{32} 


! 99X 




Rx 


<- 


Rx + [SP]e{6} 


! BC9 


BD9 


Rx 


<- 


Ry + [Rz] 


| CC9 


CD9 


Rx 


<- 


Rx + [Ry][Rz] 


! DC9 


DD9 


Rx 


<- 


Rx + [Ry]e{l2> 


; EC9 


ED9 


Rx 


<- 


Rx + [Ry][Rz]e{32> 


! FC9 


FD9 


Rx 


<- 


Ry + [Rz]e{32> 



! Opcode assignment J Code 



Implementation 
(Rx,Rx+l) <- (Ry,Ry+l) + (Rz,Rz+l) 



FADD.80 



F09 



The format of the non-generalized FADD.80 instruction is 



F 


n 

u 


9 ; x ; 


y i z \ 


A 




A A 


A A 




1 


1 


1 1 
1 

! Ry, 






! 


Rx , Rx+1 




1 


Opcode 





Rz, Rz+l is source operand 



Ry, Ry+1 is source operand 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 
FLOATING POINT UNDERFLOW 
FLOATING POINT OVERFLOW 



FLOATING POINT INSTRUCTIONS 



Table 7-1. Result Matrix for FADD, FSUB and FSUBR 



If OP1 is 



and OP2 is 



then result is 



i 



Zero 
Zero 
Zero 



; Zero 

\ Denorm , Normal 

| Infinity 



| Zero with sign 

I OP2 

i 

i 



(1) 



0P2 



, Denorm, Normal 
I Denorm, Normal 
[ Denorm, Normal 



I Zero 

! Denorm, Normal 



Infinity 



OPl 

computed 

0P2 



(1) 



J Infinity 
! Infinity 
s Infinity 



i 



Zero 



i Denorm , Normal 
\ Infinity 



; opi 
; opi 

J OPl or Invalid 



(2) 



Magnitude subtraction occurs if 
FADD or the same in FSUB or FSUBR. 



the operands' signs are different in 



(1) If magnitude subtraction produces a zero result, then the sign is 
determined by the rounding mode. The result is -0 if the rounding 
mode is toward minus infinity, and +0 otherwise. Magnitude 
addition preserves the sign of the operands. 



(2) Magnitude subtraction of two Infinities causes an Invalid Operation 
exception. 



FLOATING POINT INSTRUCTIONS 



7.2 FLOATING POINT DIVISION 

Divide the source operands and place the result into Operand 1. With 
the two operand forms, Operand 1 is replaced by Operand 1 divided by 
Operand 2 (Operand 2 divided by Operand 1 for FDIVR) . With the three 
operand forms, Operand 1 is replaced by Operand 2 divided by Operand 3 
(Operand 3 divided by Operand 2 for FDIVR) . The result matrix is shown 
below. 



7.2.1 FDIV 

7.2.2 FDIVR 



Floating Point Division 
Floating Point Division Reversed 









| FDIV. 32 


FDIV. 64 


! Implementation 


i 3CC 


3DC 


! Rx <- Ry/Rz 


1 4CC 


4DC 


| Rx <- Rx/e{l6} 


! 6CC 


6DC 


! Rx <- Ry/e{32} 


! 7CC 




! Rx <- Ry/=e{32) 


! BCC 


BDC 


! Rx <- Ry/[Rz] 


! ccc 


CDC 


i Rx <- Rx/[Ry][Rz] 


! dcc 


DDC 


J Rx <- Rx/[Ry]e{l2} 


i ECC 


EDC 


J Rx <- Rx/[Ry][Rz]e{32} 


J FCC 


FDC 


! Rx <- Ry/[Rz]e{32} 



1 FDIVR. 32 


FDIVR. 64 


] Implementation 


1 4CD 


4DD 


| Rx <- e(l6}/Rx 


J 6CD 


6DD 


| Rx <- e(32}/Ry 


| 7CD 




i Rx <- =e{32)/Ry 


J BCD 


BDD 


! Rx <- [Rz]/Ry 


| CCD 


CDD 


! Rx <- [Ry] [Rz]/Rx 


| DCD 


DDD 


! Rx <- [Ry]e{l2}/Rx 


| ECD 


EDD 


! Rx <- [Ry][Rz]e{32}/Rx 


! FCD 


FDD 


1 Rx <- [Rz]e{32}/Ry 



, Opcode assignment | Code 
! FDIV. 80 ! FOC 



Implementation 
(Rx,Rx+l) <- (Ry,Ry+l)/(Rz,Rz+l) 



FLOATING POINT INSTRUCTIONS 



The format of the non-generalized FDIV.80 instruction is 



!F|o!c|x|y|z| 



Opcode 



Rz, Rz+1 is source operand 



Ry, Ry+l is source operand 



Rx, Rx+1 is result operand 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 
FLOATING POINT UNDERFLOW 
FLOATING POINT OVERFLOW 
FLOATING POINT DIVIDE BY ZERO 



Table 7-2. Result Matrix for FDIV and FDIVR 



If OP1 is 



and OP2 is 



then result is 



Zero 
Zero 
Zero 



Zero 

Denorm, Normal 
Infinity 



Invalid Operation exc. 
Zero with xor signs 
Zero with xor signs 



Denorm, Normal 
Denorm , Normal 
Denorm , Normal 



i 



Zero 

Denorm, Normal 

Infinity 



Divide by Zero exception 

computed 

Zero with xor signs 



Infinity 
Infinity 
Infinity 



, Zero 

[ Denorm, Normal 



Infinity 



Inf with xor signs 
Inf with xor signs 
Invalid Operation exc. 



7.3 FMUL FLOATING POINT MULTIPLY 



Multiply the source operands and place into Operand 1. With the two 
address forms, operands 1 and 2 are the sources. With the three 
operand forms, operands 2 and 3 are the sources. The result matrix is 
shown on the following page. 



FLOATING POINT INSTRUCTIONS 



Opcode 












FMUL.32 


FMUL.64 






Implementation 


18x 


lCx 


RX 


<- 


Rx * 


Rw 


3C8 


3D8 


Rx 


<" 


Ry * 


RZ 


4C8 


4D8 


Rx 


<- 


Rx * 


e{l6l 


6C8 


6D8 


Rx 


<" 


Ry * 


e{32} 


7C8 




Rx 


<- 


Ry * 


=e{32} 


98x 




Rx 


<- 


RX * 


[SP]e{6) 


BC8 


BD8 


Rx 


<- 


Ry * 


tRz] 


CC8 


CD8 


RX 


<- 


Rx * 


[Ry][Rz] 


DC8 


DD8 


Rx 


<- 


Rx * 


[Ry]e{l2} 


EC8 


ED8 


RX 


<- 


Rx * 


[Ry][Rz]e{32} 


FC8 


FD8 


Rx 


<- 


Ry * 


[Rz]e{32} 



| Opcode assignment ] Code ] 



Implementation 



I FMUL.80 



F08 



(Rx,Rx+l) <- (Ry,Ry+l) * (Rz,Rz+l) 



The format of the non-generalized FMUL.80 instruction is 



!F|0|9|x!y;z! 



Opcode 



Rz, Rz+1 is source operand 



Ry, Ry+l is source operand 



Rx, Rx+1 is result operand 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 
FLOATING POINT UNDERFLOW 
FLOATING POINT OVERFLOW 



FLOATING POINT INSTRUCTIONS 



Table 7-3. Result Matrix for MULTIPLY 



If OP1 is 



! and OP2 is 



then result is 



Zero 
Zero 
Zero 



Zero 

Denorm, Normal 

Infinity 



Zero with xor signs 
Zero with xor signs 
Invalid Operation 



Denorm, Normal 
Denorm, Normal 
Denorm, Normal 



Zero 

Denorm, Normal 

Infinity 



Zero with xor signs 

computed 

Inf with xor signs 



; Infinity 
\ Infinity 
[ Infinity 



Zero 

Denorm, Normal 

Infinity 



Invalid Operation 
Inf with xor signs 
Inf with xor signs 



7.4 FREM FLOATING POINT REMAINDER 

Divide Rz by Ry (note that FREM is defined by FDIVR) to produce the 
full-length integer quotient rounded to nearest even. If the rounded 
quotient is zero, the instruction terminates. Otherwise, Rx is 
replaced by the low order 64 bits of the rounded two ' s complement 
integer quotient and Rz is replaced by the remainder in floating point 
form. The remainder is defined to be Rz - ( (Rz/Ry rounded to the 
nearest integer) * Ry) so that -0.5 * abs (divisor) <= remainder <= +0.5 
* abs (divisor) . The remainder need not be rounded because it is exact. 
A zero remainder has the same sign as the dividend. 

The contents of Rx, Rz (and Rz+1 in extended), are undefined if the 
register specifiers Rx and Rz are the same (Rx and Rz+1 for Double 
Extended) . Integer overflow is ignored when storing the quotient into 
Rx. 



Opcode assignment , Code 



i 



Implementation 



i 



FREM. 32 
FREM. 64 
FREM. 80 



B04 ] if Rz/Ry not zero; Rx <- quot, Rz <-rem \ 
B05 | if Rz/Ry not zero; Rx <- quot, Rz <-rem j 
B06 [ if Rz/Ry not zero; Rx <- quot, Rz <-rem J 



FLOATING POINT INSTRUCTIONS 



The format of the non-generalized FREM.xx instruction is 



J B | !0P2| x i y J z J 



dividend in Rz, remainder to Rz 



divisor in Ry 



integer quotient returned in Rx 



Opcode 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 



Table 7-4. Result Matrix for FREM 



If OP1 is 



and 0P2 is 



then result is 



i 



Zero 
Zero 
Zero 



Zero 

Denorm, Normal 

Infinity 



Invalid Operation 
NOP 

NOP 



, Denorm, Normal 
J Denorm, Normal 
j Denorm, Normal 



Zero 

Denorm, Normal 

Infinity 



Invalid Operation 

computed 

NOP 



Infinity 
Infinity 
Infinity 



, Zero 

] Denorm, Normal 

! Infinity 



i 



Invalid Operation 
] Invalid Operation 
! Invalid Operation 



FLOATING POINT INSTRUCTIONS 



7.5 FSQR FLOATING POINT SQUARE ROOT 

Find the square root of the source and place into Operand 1. With the 
two address forms, Operand 2 is the source. With the three address 
forms, Operand 3 is the source. 









; FSQR. 32 


FSQR. 54 




Implementation 


1 3CE 


3DE 


! Rx <- 


Rz**l/2 


! 4CE 


4DE 


! Rx <- 


e{l6>**l/2 


1 6CE 


6DE 


! Rx <- 


e{32}**l/2 


J BCE 


BDE 


! Rx <- 


[Rz]**l/2 


! CCE 


CDE 


1 Rx <- 


[Ry][Rz]**l/2 


! DCE 


DDE 


! Rx <- 


[Ry]e{l2}**l/2 


] ECE 


EDE 


! Rx <- 


[Ry]tRz]e{32}**l/2 


1 FCE 


FDE 


! Rx <- 


[Rz]e{32}**l/2 



[ Opcode assignment | Code [ Implementation 



FSQR. 80 



FOE 



(Rx,Rx+l) <- (RZ,RZ+l)**l/2 



The format of the non-generalized FSQR. 80 instruction is 



! f 



i i E ! x J 



1 z ' 



Opcode 



Rz, Rz+1 is source operand 



Rx, Rx+1 is result operand 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 



FLOATING POINT INSTRUCTIONS 



Table 7-5. Result Matrix for FSQR 



i 



If OP1 is 



i 



then result is 



i Neg. Infinity 

] Neg. (Denorm, Normal) 



; Invalid Operation 
] Invalid Operation 



i 



Zero 



i 



0P1 (square root of -0 is -0) 



Pos. (Denorm, Normal) 
Pos. Infinity 



computed 
OP1 



7.6 FLOATING POINT SUBTRACTION 

Place the difference of the source operands into Operand 1. With the 
two operand forms. Operand 1 is replaced by Operand 1 minus Operand 2 
(Operand 2 minus Operand 1 for FSUBR) . With the three operand forms, 
Operand 1 is replaced by Operand 2 minus Operand 3 (Operand 3 minus 
Operand 2 for FSUBR) . The result matrix is shown on the page following 
the FADD instruction. 



7.6.1 FSUB 

7.6.2 FSUBR 



Floating Point Subtraction 
Floating Point Subtraction Reversed 



1 FSUB. 32 


FSUB. 64 


Implementation 


! 1AX 


1EX 


RX 


<- 


Rx - Rw 


1 3CA 


3DA 


Rx 


<- 


Ry - Rz 


\ 4CA 


4DA 


Rx 


<- 


Rx - e{l6} 


! 6CA 


6DA 


Rx 


<- 


Ry - e{32} 


] 7CA 




Rx 


<- 


Ry - =e{32} 


] 9Ax 




Rx 


<- 


Rx - [SP]e{6} 


\ BCA 


BDA 


Rx 


<- 


Ry - [Rz] 


1 CAC 


CDA 


Rx 


<- 


[Ry] - [Rz] 


; DAA 


DDC 


Rx 


<- 


[Ry] - e{l2} 


I ECA 


EDA 


Rx 


<- 


[Ry] - [Rz]e{32} 


! FCA 


FDA 


Rx 


<" 


Ry - [Rz]e{32} 
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FLOATING POINT INSTRUCTIONS 









| FSUBR.32 


FSUBR.64 


I mplementat ion 


J 1AX 


1EX 


Rx <- Rw - Rx 


| 4CB 


4DB 


Rx <- e{l6> - Rx 


J 6CB 


6DB 


Rx <- e{32> - Ry 


1 7CB 




Rx <- =e{32> - Ry 


! 9AX 




Rx <- [SP]e{6l - Rx 


1 BCB 


BDB 


Rx <- [Rz] - Ry 


J CCB 


CDB 


Rx <- [Rz] - [Ry] 


! DCB 


DDB 


Rx <- e{l2} - [Ry] 


\ ECB 


EDB 


Rx <- [Rz]e{32} - [Ry] 


! FCB 


FDB 


Rx <- [Rz]e{32] - Ry 



Opcode assignment [ Code [ Implementation 



FSUB.80 



FOA 



(RX,RX+1) <- (Ry,Ry+l) - (Rz,Rz+l) 



The format of the non-generalized FSUB.80 instruction is 



I f I o ! a ! x ! y ! z ! 



Rz, Rz+1 is source operand 



Ry, Ry+1 is source operand 



Rx, Rx+1 is result operand 



Opcode 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 
FLOATING POINT UNDERFLOW 
FLOATING POINT OVERFLOW 



- 11 
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8 ASCII ARITHMETIC INSTRUCTIONS 

ASCII arithmetic instructions operate on ASCII encoded decimal strings. 
Operands are in ASCII format, with the ASCII digits in the set ['00', 
'30' to '39'] hex. Source operands not conforming to the ASCII format 
will produce undefined results. 



ASCII. ADD ASCII Addition 

ASCII.ADDC ASCII Addition Generate Carry 

ASCI I. SUB ASCII Subtract 

ASCII.SUBC ASCII Subtract Generate Carry 



8.1 MULTIPLE PRECISION ASCII SUBTRACTION 

ASCII subtraction is implemented through two types of instructions on 
the ELXSI. The ASCI I. SUB instruction returns the magnitude of the 
result of the subtraction in Rx, with the sign bit of the result 
returned in Rt. The ASCII.SUBC instruction returns the 9's complement 
of the result if the result is negative, otherwise it returns the true 
magnitude of the result. 

The ASCII.SUBC instructions would typically be used in a situation 
where the numeric string to be operated on exceeds the register length, 
or otherwise where multiple precision subtraction is required. In the 
majority of cases where ASCII.SUBC is used, the returned result will be 
positive; if the result is negative, then an additional subtraction is 
required in order to determine the true magnitude of the result. (See 
Section 6.1 on multiple precision integer arithmetic for a discussion 
of the carry mechanism) . 



ASCII ARITHMETIC INSTRUCTIONS 



As an example to illustrate the postive result case for multiple 
precision subtraction, 3 is subtracted from 1001. Assuming that the 
register width is 4 characters, 

The example is 

0001 0001 
- 0000 0003 



Doing the low order subtract, 



0001 




0001 


- 0003 


becomes 


+ 9996 

+ 1 



(9's complement of 0003) 

(complement of decimal carry, initially 0) 



9998 



Since there is no carry, a 1 is placed in the decimal carry bit (no 
carry amounts to a borrow from the next segment) . 

Doing the high order subtract, 



0001 




0001 




0000 


becomes 


9999 











(complement of decimal carry) 



0000 

Since there is a carry, the result is positive. A zero goes into the 
sign register. Since this is not a generate carry instruction, a zero 
is placed in the decimal carry bit. Overflow does not occur since the 
true result can be represented in the 4 digits. 



ASCII ARITHMETIC INSTRUCTIONS 



Another example will illustrate the negative result case for multiple 
precision subtraction. 

The example is 

0001 0001 
- 0000 0003 



Doing the low order subtract, 

1 0001 0001 
- 1 0003 becomes 9996 
1 (complement of decimal carry, initially 0) 



9998 

Since there is no carry, a 1 is placed in the decimal carry bit, 

Doing the high order subtract, 

0001 0001 

0001 becomes 9998 

(complement of decimal carry) 



9999 



Since there is no carry, the result is negative. A one goes into the 
sign register. Since this is not a generate carry instruction, 
(ASCII.ADDC) a zero is placed in the decimal carry bit. The target 
result register receives the absolute value of 9999 (= 0001) as the 
result is negative. So the result that we have now is 

negative 0001 9998 

This is clearly not the result that is desired, since the actual answer 
is -2. There are two ways to correct this answer, both signaled by a 
negative result, that is, a 1 in the target sign register. The first 
is to simply reperform the subtraction, switching the subtrahend and 
minuend. 

The second is to form the 9's complement of the low order segments by 
subtracting them from with the ASCII.SUBC instruction, and then 
subtracting from the high order segment, to take into account any 
borrow that might have been generated. 



ASCII ARITHMETIC INSTRUCTIONS 



In the example above, we get 

0000 0000 

- 9998 becomes 0001 

1 (complement of decimal carry) 



Since there is no carry, a 1 is placed in the decimal carry. 
The high order segment is 

0001 0001 

- 0000 becomes 9999 

(complement of decimal carry) 

0000 

Thus, the actual ASCII answer that is wanted is returned 

negative 0000 0002 

8.2 ASCII ADDITION 

Replace Rx with the ASCII decimal sum of Ry + Rz + decimal carry. 
ASCII. ADD clears the decimal carry-out, whereas ASCII. ADDC sets the 
carry-out if generated. 



8.2.1 ASCI I. ADD ASCII Addition 

8.2.2 ASCI I. ADDC ASCII Addition Generate Carry 



Opcode assignment | Code 



Implementation 



ASCI I. ADD 
ASCI I. ADDC 



708 I Rx <- Ry + Rz + carry 

709 J Rx <- Ry + Rz + carry 



ASCII ARITHMETIC INSTRUCTIONS 



The formats of these non-generalized instructions are 



7 ! 0|8 ix|y |z! 



I r, I 
I 



! 7 ! o 



9 ; x ! y [ z 



Opcode 



ASCI I. ADD 



ASCII.ADDC 



Rz is source operand 



Ry is source operand 



Rx is destination operand 



Instruction Specific Exceptions: None 



8.3 ASCII SUBTRACTION 

Extract the decimal value from Ry and sum with the decimal value 9 ' s 
complemented from Rz + the complement of the decimal carry. For 
ASCII. SUB, place the ASCII encoded magnitude of the sum into Rx, place 
the sign of the result into Rt (0 for a positive result, 1 for a 
negative result), and clear the decimal carry. For ASCII. SUBC, place 
the ASCII encoded sum into Rx and set the decimal carry to the 
complement of the carryout of the sum. 



8.3.1 ASCII. SUB 

8.3.2 ASCII. SUBC 



ASCII Subtract 
ASCII Subtract Generate Carry 



J Opcode assignment [ Code \ Implementation ] 

i ASCII. SUB J 90E | Rx <- mag(Ry - Rz - carry); Rt <- sign \ 
I ASCI I. SUBC J 70B J Rx <- Ry - Rz - carry [ 



ASCII ARITHMETIC INSTRUCTIONS 



The formats of these non-generalized instructions are 



! E j x [ y J z [ t 



! ! 



ASCI I. SUB 



! 7 ; J 9 J X J y 



Rt receives sign of result 



ASCII.SUBC 



Opcode 



Rz is source operand 



Ry is source operand 



Rx is destination operand 



It is important to note that the ASCII. SUB instruction behaves 
differently than the ASCII.SUBC instruction, in that the MAGNITUDE of 
the result is returned. There is no difference when the result is 
positive, but when it is negative, ASCII.SUBC returns the 9's 
complement of the magnitude, while this instruction returns the sign as 
negative and the true magnitude of the result. This is most often 
exactly what is preferred when ASCII arithmetic is being performed on 
ASCII strings of length eight or less. However, when chained 
arithmetic is being performed because (at least one of) the operands 
has a length greater than eight digits, special action must be taken if 
the result of the high order subtraction using ASCII. SUB is negative. 
When this result occurs, one of two actions must be taken. The first 
possible action is to perform an ASCII.SUBC on all of the low order 
segments of the result, subtracting each segment from 0. This will 
convert the 9's complement values into true magnitude values. Then in 
order to take in account a possible carry out from this conversion, use 
ASCII. SUB to subtract from the high order segment of the result. The 
second possible action is to just reperform the subtraction, reversing 
the subtrahend and the minuend. 

Obviously, the same number of subtractions are performed in both cases, 
so the choice of method depends on minimizing the number of supporting 
operations which are required, such as reloading operands. 



Instruction Specific Exceptions: none 
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9 LOGICAL INSTRUCTIONS 



All logical operations are performed on 
Immediate operands are SIGN extended, 
unsigned integers modulo 64. 



64-bit unsigned quantities, 
and all shift distances are 



Logical Instructions 



AND 

OR 

XOR 

NOT 

SET. BIT 

CLEAR. BIT 

TOGGLE. BIT 

FIND. FIRST 

ROL 

ROR 



Boolean AND 
Logical Or 

Logical Exclusive Or 
Logical Not 



Find First Logical One 
Logical Rotate Left 
Logical Rotate Right 



Logical Shift Instructions 



SLL 

SLL1 

SLL2 

SLL3 

SRL 



Shift Left Logical 
Shift Left Logical by 1 
Shift Left Logical by 2 
Shift Left Logical by 3 
Shift Right Logical 



9.1 FULLWORD LOGICAL OPERATIONS 



With 2 operand addressing, operand 1 is replaced by operand 1 <op> 
'Last Operand'. With 3 operand addressing, operand 1 is replaced by 
operand 2 <op> 'Last Operand' . The logical NOT operation replaces 
operand 1 with the l's complement of 'Last Operand'. 



LOGICAL INSTRUCTIONS 



9.1.1 AND Logical AND 

9.1.2 OR Logical OR 

9.1.3 NOT Logical NOT 

9.1.4 XOR Logical Exclusive OR 



1 AND 


OR NOT 


XOR 


Implementation 


! 31C 


3 ID 


31E 


31F 


Rx <- Ry <op> Rz 


\ 41C 


41D 


41E 


41F 


Rx <- Rx <op> e(l6} 


! 51C 


51D 




51F 


Rx <- Ry <op> =e{l2} 


! 61C 


61D 


61E 


61F 


Rx <- Ry <op> e{32} 


\ 71C 


71D 




71F 


Rx <- Ry <op> =e{32} 


; bic 


BID 


B1E 


B1F 


Rx <- Ry <op> [Rz] 


| C1C 


C1D 


C1E 


C1F 


Rx <- Ry <op> [Ry][Rz] 


! dig 


DID 


DIE 


D1F 


Rx <- Ry <op> [Ry]e{l2} 


I E1C 


E1D 


E1E 


E1F 


Rx <- Ry <op> [Ry][Rz]e{32} 


1 F1C 


FID 


FIE 


F1F 


Rx <- Ry <op> [Rz]e{32} 



Instruction Specific Exceptions: none 



9.2 BIT-WISE LOGICAL OPERATIONS 



The bit specified in 'Last Operand' is set for SET. BIT, cleared for 
CLEAR. BIT, and complemented for TOGGLE. BIT. 'Last operand', a literal 
encoded in the instruction, is used modulo 64. 



9.2.1 SET. BIT 

9.2.2 CLEAR. BIT 

9.2.3 TOGGLE. BIT 



Opcode assignment [ Code 



Implementation 



SET. BIT 
CLEAR. BIT 
TOGGLE. BIT 



I 305 
! 306 
! 307 



Rx <- Rx<SET>bit 

Rx <- Rx<CLEAR>bit 

RX <- Rx<COMPLEMENT>bit 



LOGICAL INSTRUCTIONS 



The formats for the instructions are 



3 ; o ; 5 ; x ; bit n 

3 I ! 6 I x I bit n 
3 ! ! 7 ! x ! bit n 



A A 



SET. BIT instruction 



CLEAR. BIT instruction 



TOGGLE. BIT instruction 



Bit position in Rx 



Register Rx 



Opcode 



Instruction Specific Exceptions: none 



9.2.4 FIND. FIRST Find First Logical One 



Starting at bit 0, scan a 64-bit string of 'Last Operand' for the first 
occurrence of a set bit. If found, the bit position is returned to 
Operand 1, otherwise a -1 is returned. 







; FIND. FIRST 


] Implementation 


I 317 


[ Rx <- first set bit position Rz 


! 417 


| Rx <- first set bit position e{l6} 


| 617 


j Rx <- first set bit position e{32} 


! B17 


I Rx <- first set bit position [Rz] 


; ci7 


\ Rx <- first set bit position [Ry][Rz] 


! D17 


[ Rx <- first set bit position [Ry]e(l2} 


I E17 


| Rx <- first set bit position [Ry][Rz]e(32} 


| F17 


\ Rx <- first set bit position [Rz]e{32} 



Instruction Specific Exceptions: none 
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9.3 LOGICAL ROTATE OPERATIONS 

Rotate an image of Operand 2 by the value in "Last Operand' and place 
into operand 1. The unsigned value of Last Operand is used modulo 64. 



9.3.1 ROL Logical Rotate Left 

9.3.2 ROR Logical Rotate Right 



Opcode 

I rvOL Rujci | xiiipxtsiiieiiuctoxuii f 



1 ROL ROR I Implementation ' 



i 314 315 | Rx <- Ry rotated Rz bits J 

\ 514 515 | Rx <- Ry rotated =e{l2>bits ; 



714 715 J Rx <- Ry rotated =e{32> bits 



Instruction specific exceptions: none 



9.4 LOGICAL SHIFT OPERATIONS 



Shift an image of Operand 2 by the count in "Last Operand' and place 
into operand 1. The unsigned value of 'Last Operand' is used modulo 
64. The fill bit is zero. 



9.4.1 SLL Shift Left Logical 

9.4.2 SLR Shift Right Logical 



Opcode 



SLL SRL , Implementation 



1 310 311 j Rx <- Ry shifted by Rz ' 



SLL will not cause an overflow exception, whereas SLA -Shift Left 
Arithmetic- will. The sign bit is not maintained in either 
instruction. 



Instruction Specific Exceptions: none 



LOGICAL INSTRUCTIONS 



9.5 LEFT SHIFT OPERATIONS FOR FAST ARRAY INDEXING 



SLL1, SLL2 ana SLL3 perform left shifts by 1, 2, 
indexing into 16-, 32-, ana 64-bit word arrays, 
by the value of 'Last Operand' shifted left by 1, 
bit is zero. 



or 3 to facilitate 
Operand 1 is replaced 
2, or 3. The fill 



9.5.1 SLL1 Shift Left Logical by 1 

9.5.2 SLL2 Shift Left Logical by 2 

9.5.3 SLL3 Shift Left Logical by 3 













1 SLL1.16 SLL1.32 


SLL1.64 J 


Implementation 




| 394 


3A4 


3B4 ! 


Rx <- Ry 


shift left by 1 


| 494 


4A4 


4B4 I 


Rx <- e{l6} 


shift left by 1 


; 694 


6A4 


6B4 


Rx <- e{32} 


shift left by 1 


1 B94 


BA4 


BB4 | 


Rx <- [Rz] 


shift left by 1 


\ C94 


CA4 


CB4 ! 


Rx <- [Ry][Rz] 


shift left by 1 


J D94 


DA4 


DB4 ; 


Rx <- [Ry]e{l2) 


shift left by 1 


; E94 


EA4 


EB4 


Rx <- [Ry][Rz]e{32} 


shift left by 1 


j F94 


FA4 


FB4 ! 


Rx <- [Rz]e{32> 


shift left by 1 













SLL2.16 SLL2.32 


SLL2 . 64 


Implementation 








ODx 


Rx <- Rw 


shift left by 2 


395 


3A5 


3B5 


Rx <- Rz 


shift left by 2 


495 


4A5 


4B5 


Rx <- e{l6> 


shift left by 2 


695 


6A5 


6B5 


Rx <- e{32} 


shift left by 2 




8DX 




Rx <- [SP]e{6} 


shift left by 2 


B95 


BA5 


BB5 


Rx <- [Rz] 


shift left by 2 


C95 


CA5 


CB5 


Rx <- [Ry][Rz] 


shift left by 2 


D95 


DA5 


DB5 


Rx <- [Ry]e{l2} 


shift left by 2 


E95 


EA5 


EB5 


Rx <- [Ry][Rz]e{32> 


shift left by 2 


F95 


FA5 


FB5 


Rx <- [Rz]e{32> 


shift left by 2 



LOGICAL INSTRUCTIONS 



Opcode — 

1 SLL3.16 SLL3.32 


SLL3.64 


Implementation 






OEx 


Rx <- Rw 


shift left by 3 


! 396 


3A6 


3B6 


Rx <- Rz 


shift left by 3 


! 496 


4A6 


4B6 


Rx <- e(l6} 


shift left by 3 


! 696 


6A6 


6B6 


Rx <- e{32} 


shift left by 3 




8 Ex 




Rx <- tSP]e{6> 


shift left by 3 


\ B96 


BA6 


BB6 


Rx <- [Rz] 


shift left by 3 


1 C96 


CA6 


CB6 


Rx <- [Ry][Rz] 


shift left by 3 


! D96 


DA6 


DB6 


Rx <- [Ry]e{l2> 


shift left by 3 


\ E96 


EA6 


EB6 


Rx <- [Ry][Rz]e{32> 


shift left by 3 


! F96 


FA6 


FB6 


Rx <- [Rz]e{32> 


shift left by 3 



Use these instructions on the index of the object to be addressed. 
Load another register with the base address of the array, then use the 
BASE, INDEX addressing mode. Note the functional equivalence of using 
SLL1.64 to double the index and using ADD. 64 to sum the index to 
itself. 



Instruction Specific Exceptions: none 
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10 RELATIONAL TEST INSTRUCTIONS 

The Relational Test instructions test two operands for a specified 
relation. If the relation is true, then the instruction performs the 
operation. If the relation is false, then no action is taken. 



Integer Compare Instructions 

CMP. BR Compare Signed Integer and Branch 

Program counter Relative 
CMPU.BR Compare Unsigned Integer and Branch 

Program Counter Relative 
CMP Compare Signed Integer and either 

Set Register or Generate Exception 
CMPU Compare Unsigned Integer and either 

Set Register or Generate Exception 



Floating Point Compare Instructions 

FCMP Compare Floating Point and either 

Set Register or Generate Exception 

FCMPX Compare Floating Point 

Unordered Relation excepted 
and either Set Register 
or Generate Exception 

FCMP. BR Compare Floating Point and Branch 

Program Counter Relative 

FCMPX. BR Compare Floating Point 

Unordered Relation excepted 

and Branch Program Counter Relative 



Byte String Compare Instructions 

CMPB.BR Compare Byte Strings and Branch 

Program Counter Relative 

CMPB.BR. CONST Compare Byte String Against Constant 

and Branch Program Counter Relative 

CMPB.TEST Compare Byte Strings and 

Generate Test Result 



The order of comparison is: 

Operand 1 <relation> Operand 2 



All integer type compares are performed on 64-bit quantities. The 
integer compare instructions that use signed integer operands first 
sign extend all operands to 64 bits before the compare. The unsigned 
integer compare instructions zero extend all operands before the 
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compare. A test performed with the unsigned integer compare will find 
a quantity with the sign bit on greater than a quantity with the sign 
bit off. Otherwise, these two types of instructions perform 
identically. 

The instructions in this section use a 16-bit appendage. The first 
four high order bits of the appendage are for the compare condition 
field (ccf ) . The remaining 12 bits are used to specify the appropriate 
action for the instruction should the test be successful. The 
appendage in its entirety is shown below: 



bit - 



1 2 

ccf 



General Appendage Format 
4 5 6 7 8 9 10 11 12 13 14 15 



Supplemental Information for Instruction 



The compare condition field uses four bits to specify the relation to 
be tested. Refer to Table 10-1. The unordered bit is only used for 
the floating point compares to allow the detection of NaN's. A further 
discussion on unordered relations may be found in Chapter 3, "Data 
Representations", and within the descriptions of the floating point 
compare instructions. For the integer and string compare instructions, 
the unordered bit (bit 0) is reserved. 

The 4-bit compare condition segment has the following format: 



bit 



Compare Condition Field Format 
12 3 



u 


L , E | G | 


A 

1 


AAA 

! | | Grea 




i i 
i i 

j [ Equal to 
| Less than 


] 


Unordered 
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Table 10-1. Table of Compare Condition Field Relations 



] Code 


Floating Point 


Integer or String 


1 1 


G 


G 


\ 2 


E 


E 


! 3 


EG 


EG 


! 4 


L 


L 


', 5 


LG 


LG 


1 6 


LE 


LE 


! 7 


LEG 


LEG 


! 8 


U 




i 9 


UG 


G 


! io 


UE 


E 


! ii 


UEG 


EG 


! 12 


UL 


L 


! 13 


ULG 


LG 


] 14 


ULE 


LE 


! 15 


ULEG 


LEG 



The compare and branch instructions use the remaining 12-bit segment of 
the appendage to hold a two's complement PC relative offset for the 
branch . 



bit 



-COMPARE AND BRANCH APPENDAGE FORMAT- 
<two's complement PC relative offset> 
6 7 8 9 10 11 12 13 14 15 



For the compare and set register instructions, the 12-bit segment has 
the following format. 



: o : o 



bit 



-COMPARE AND SET REGISTER APPENDAGE FORMAT- 

0000000000| 
5 6 7 8 9 10 11 12 13 14 15 



Bit 4 differentiates this instruction from the compare and generate 
exception form. Bits 5 through 15 are unused and must be '0'. Bits 
0-62 of Rx are cleared, then the least significant bit of Rx is set if 
the compare is true, and is cleared if the compare is false. 
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For the compare and generate exception instructions, the 12-bit segment 
has the following format. 



-COMPARE AND GENERATE EXCEPTION APPENDAGE FORMAT- 
| 1 ] | <exception> \ 

bit 4 5 6 7 8 9 10 11 12 13 14 15 



Bit 4 is ' 1 ' to identify this format , and bits 5 through 7 are unused 
and must be '0'. Bits 8 through 15 contain a value which is included 
in the message to the exception handler. 

All Branch Relative instructions use the address of the first byte of 
the branch instruction as the base for the offset. 



10.1 INTEGER COMPARE 

The Integer Compare instructions perform a relational test on signed or 
unsigned integer operands. 



10-1.1 Compare Integer and Branch Program Counter Relative 

Compare integer operands. If true, branch program counter relative by 
a 12-bit signed integer byte offset specified in the appendage. The 
relational test is specified in the compare condition segment. 
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10.1.1.1 CMP. BR 

10.1.1.2 CMPU.BR 



Compare Signed Integers and Branch PC Relative 
Compare Unsigned Integers and Branch PC Relative 



Opcode 



| CMP. BR. ( 


3 .16 


.32 


.64 


Implementation 












033 


Rx <rel> Rw 




branch 








333 


Ry <rel> Rz 




branch 


! 430 


431 


432 


433 
533 


Rx <rel> e{l6) 
Ry <rel> =e(l2) 




branch 
branch 


! 630 


631 


632 
A32 


633 
733 


Ry <rel> e{32} 
Ry <rel> =e(32} 
Rw <rel> [Ry][Rz] 




branch 
branch 
branch 


| B30 


B31 


B32 


B33 


Ry <rel> [Rz] 




branch 


\ C30 


C31 


C32 


C33 


Rx <rel> [Ry]e{l2} 




branch 


| D30 


D31 


D32 


D33 


Rx <rel> [Ry][Rz]e 


(32) 


branch 


| E30 


E31 


E32 


E33 


Rx <rel> [Ry][Rz]e 


132} 


branch 


| F30 


F31 


F32 


F33 


Ry <rel> [Rz]e{32} 




branch 





— Opcode 








| CMPU.BR. 


.8 .16 


.32 


.64 


Implementation 










337 


Ry <rel> Rz 


branch 


! 434 


435 


436 


437 


Rx <rel> e{l6} 


branch 








537 


Ry <rel> =e{l2) 


branch 


I 634 


635 


636 


637 


Ry <rel> e{32) 


branch 








737 


Ry <rel> =e{32} 


branch 


! B34 


B35 


B36 


B37 


Ry <rel> [Rz] 


branch 


! C34 


C35 


C36 


C37 


Rx <rel> [Ry]e{l2} 


branch 


; D34 


D35 


D36 


D37 


Rx <rel> [Ry][Rz]e{32} 


branch 


! E34 


E35 


E36 


E37 


Rx <rel> [Ry][Rz]e{32} 


branch 


1 F34 


F35 


F36 


F37 


Ry <rel> [Rz]e{32} 


branch 



Instruction Specific Exceptions: none 



10.1.2 Compare Integers and either Set Register or Generate Exception 

Compare integer operands. If true, Set Register or Generate Exception. 
The "Set Register" occurs when bit 4 of the appendage is '0'. If the 
compare is true, set Rx equal to one; if the compare is false, clear 
Rx. The "Generate Exception" occurs when bit 4 of the appendage is 
' 1'. If the compare is true, then generate the exception specified in 
the appendage. The relational test considers the operands to be signed 
integers for CMP, and unsigned integers for CMPU. 
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10.1.2.1 CMP 

10.1.2.2 CMPU 

















CMP. 8 


CMP. 16 


CMP. 32 


CMP. 64 


Implementation 










323 


Rx, 


exc; 


<- Ry <rel> 


Rz 


420 


421 


422 


423 


Rx, 


exc; 


<- Rx <rel> 


e(l6} 








523 


Rx, 


exc; 


<- Ry <rel> 


=e {12} 


620 


621 


622 


623 


Rx, 


exc; 


<- Ry <rel> 


e{32} 








723 


Rx, 


exc; 


<- Ry <rel> 


=e{32} 


B20 


B21 


B22 


B23 


Rx, 


exc; 


<- Ry <rel> 


[Rz] 


C20 


C21 


C22 


C23 


Rx, 


exc; 


<- Rx <rel> 


[Ry][Rz] 


D20 


D21 


D22 


D23 


Rx, 


exc; 


<- Rx <rel> 


[Ry]e{l2} 


E20 


E21 


E22 


E23 


Rx, 


exc; 


<- Rx <rel> 


[Ry][Rz]e{32} 


F20 


F21 


F22 


F23 


Rx, 


exc; 


<- Ry <rel> 


[Rz]e(32} 



Opcode 



CMPU. 8 


CMPU. 16 


CMPU. 32 


CMPU. 64 


Implementation 










327 


Rx, 


exc; <- Ry <rel> 


Rz 


424 


425 


426 


427 


Rx, 


exc; <- Rx <rel> 


e(l6} 








527 


Rx, 


exc; <- Ry <rel> 


=e {12} 


624 


625 


626 


627 


Rx, 


exc; <- Ry <rel> 


e(32} 








727 


Rx, 


exc; <- Ry <rel> 


=e{32} 


B24 


B25 


B26 


B27 


Rx, 


exc; <- Ry <rel> 


[Rz] 


C24 


C25 


C26 


C27 


Rx, 


exc;- <- Rx <rel> 


[Ry][Rz] 


D24 


D25 


D26 


D27 


Rx, 


exc; <- Rx <rel> 


[Ry]e{l2} 


E24 


E25 


E26 


E27 


Rx, 


exc; <- Rx <rel> 


[Ry][Rz]e{32} 


F24 


F25 


F26 


F27 


Rx, 


exc; <- Ry <rel> 


[Rz]e{32} 



Instruction Specific Exceptions: none 



10.2 FLOATING POINT COMPARE 

All floating point compare instructions first test for unordered 
relations. The FCMP and FCMP.BR instructions generate the INVALID 
OPERATION exception only if one or both operands are signaling NaN's. 
The FCMPX and FCMPX.BR instructions generate an INVALID OPERATION 
exception if one or both operands are quiet or signaling NaN's. A NaN 
is unordered to everything, including itself. 
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The hardware exceptions are always generated before any software 
exceptions specified in the appendage. The relations that may be 
tested in the compare condition field are as follows: 

o UNORDERED 

O LESS THAN 

O EQUAL TO 

O GREATER THAN 

The following table specifies the outcome for an unordered relation 
with the FCMP, FCMP.BR, FCMPX, and FCMPX.BR instructions. The table 
headers have the following meaning: 

E Exception handler enabled for INVALID OPERATION (bit 26 in PSW) . 
U Unordered bit state in the compare condition field. 



U ACTION 

Set bit 27 in PSW. Terminate this instruction and 

execute next instruction. 

1 Set bit 27 in PSW. Test the operands and take the 

action specified in the appendage. 
X Set bit 27 in PSW. Take the INVALID OPERATION 

exception handler. 
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10.2.1 Compare Floating Point and Branch PC Relative 

Compare the 32-, 64-, or 80-bit floating point operands. If true, 
branch PC relative with the 12-bit signed integer offset specified in 
the appendage. 



10.2.1.1 FCMP.BR 

10.2.1.2 FCMPX.BR 



Compare Floating Point and Branch PC Relative 
Compare Floating Point and Branch PC Relative, 
Unordered Relation Excepted 





Opcode 














|FCMP.BR 


32 .64 


FCMPX.BR. 


32 . 64 [ Implementation 






] 13X 


12x 








1 Rx <rel> 


Rw 




branch 


J 338 


339 




33A 


33B 


! Rx <rel> 


Rz 




branch 


1 438 


439 




43A 


43B 


J Rx <rel> 


e{l6> 




branch 


1 538 






53A 




I Ry <rel> 


=e{l2} 




branch 


I 638 


639 




63A 


63B 


I Ry <rel> 


e{32} 




branch 


! 738 






73A 




! Ry <rel> 


=e{32} 




branch 


1 93x 










| Rw <rel> 


[SP]e{6)- 




branch 


! B38 


B39 




B3A 


B3B 


! Ry <rel> 


[Rz] 




branch 


| C38 


C39 




C3A 


C3B 


1 Rx <rel> 


[Ry]e{l2} 




branch 


| D38 


D39 




D3A 


D3B 


! Rx <rel> 


[Ry][Rz]e 


{32} 


branch 


; E38 


E39 




E3A 


E3B 


i Rx <rel> 


[Ry][Rz]e 


{32} 


branch 


; F38 


F39 




F3A 


F3B 


! Ry <rel> 


tRz]e{32} 




branch 


] Opcode 


assignme 


;nt 


] Code 


i 
i 


Implementation 






| FCMP. 


BR. 80 




| D09 


i 
i 


Ry,Ry+l <rel) 


> Rz,Rz+l, 


branch 


1 FCMPX.BR. 80 




] DOB 


i 
i 


Ry,Ry+l <rel) 


> RZ,Rz+l, 


branch 
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Formats for the non-generalized instructions are 



'D;o;9|o;y;z 



I " I 






i B I I y I z I 



appendage 



appendage 



FCMP.BR.80 



FCMPX.BR.80 



Opcode 



Source operand z,z+l 



Source operand y,y+l 



Instruction Specific Exceptions: FLOATING POINT INVALID OPERATION 



Table 10-2. Result Matrix for FCMP, FCMPX, FCMP.BR, FCMPX.BR 



If OP1 is 



and OP2 is 



then result is 



Zero 
Zero 
Zero 



Zero 

Denorm, Normal 

Infinity 



Zero with sign 

0P2 

0P2 



i 



Denorm , Normal 
Denorm, Normal 
Denorm, Normal 



Zero 

Denorm, Normal 

Infinity 



! 0P1 

! computed 



i 



0P2 



[ Infinity 

! Infinity 

i 
i 



Infinity 



J Zero 

[ Denorm, Normal 

! Infinity 



0P1 
0P1 
0P1 or Invalid 



10.2.2 Compare Floating Point and either Set Register or 
Generate Exception 

Compare the 32-, 64-, or 80-bit floating point operands and perform the 
action specified by bit 4 in the appendage. If bit 4 = '0', then "Set 
Register" (set Rx equal to '1' if the compare is true, and equal to '0' 
if false). If bit 4 = '1' and the compare is true then generate the 
exception specified in the appendage. 
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10.2.2.1 FCMP Compare Floating Point and either Set Register or 

Generate Exception 

10.2.2.2 FCMPX Compare Floating Point and either Set Register or 

Generate Exception, Unordered Relation Excepted 





— Opcode 








J FCMP. 32 


.64 


FCMPX. 32 


.64 


Implementation 


i 328 


329 




32A 


32B 


Rx, exc; <- Ry <rel> Rz 


! 428 


429 




42A 


42B 


Rx, exc; <- Rx <rel> e{l6} 


i 628 


629 




62A 


62B 


Rx, exc; <- Ry <rel> e{32} 


j 728 






72A 




Rx, exc; <- Ry <rel> =e{32> 


! B28 


B29 




B2A 


B2B 


Rx, exc; <- Ry <rel> [Rz] 


J C28 


C29 




C2A 


C2B 


Rx, exc; <- Rx <rel> [Ry] [Rz] 


1 D28 


D29 




D2A 


D2B 


Rx, exc; <- Rx <rel> [Ry]e{l2} 


I E28 


E29 




E2A 


E2B 


Rx, exc; <- Rx <rel> [Ry] [Rz]e{32} 


1 F28 


F29 




F2A 


F2B 


Rx, exc; <- Ry <rel> [Rz]e{32} 



Opcode assignment | Code 



Implementation 



FCMP. 80 
FCMPX. 80 



D08 

DOA 



Rx, exc; <- Ry,Ry+l <rel> Rz,Rz+l 
Rx, exc; <- Ry,Ry+l <rel> Rz,Rz+l 



The formats for the non-generalized instructions are 



!D|o;8!x|y!zi 



appendage 



D | j A | x | y 



appendage 



FCMP instruction 



FCMPX instruction 



Opcode 



Source operand z,z+l 



Source operand y,y+l 



Result operand 



Instruction Specific Exceptions: FLOATING POINT INVALID OPERATION 
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RELATIONAL TEST INSTRUCTIONS 

10.3 BYTE STRING COMPARE 

The string operand is tested against another string or a constant. 

10.3.1 CMPB.BR Compare Byte Strings and Branch 

Compare two byte strings of equal length. The comparison proceeds 
byte-wise from the respective starting addresses. Rx contains the 
address of string 1, Ry the address of string 2, and Rz contains the 
length of the strings in bytes. If string 1 <rel> string 2 is true, 
then the relative branch is taken. This instruction has an appendage 
identical in format to the integer CMP. BR instructions. 



Opcode assignment , Code 



Implementation 



CMPB.BR 



D00 



I [Rx:<st>] <rel> [Ry:<st>], Rz:<len>, br \ 



The format for the non-generalized CMPB.BR instruction is 



i D | J | x 



y J z |ccd| 12-bit disp| 



12-bit PC rel displacement 



Condition code descriptor 



Rz has length of strings in bytes 



Ry has address of string 2 



Rx has address of string 1 



Opcode 



Special Notes: 

The contents of Rx, Ry and Rz are unpredictable at the end of the 
instruction. If defined values for these registers are desired, use a 
software loop instead of these instructions. 

Instruction Specific Exceptions: none 
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10.3.2 CMPB. BR. CONST Compare Byte String Against Constant and Branch 

Compare, word-wise, a byte string against a 64- bit word constant. Rx 
contains the address of the string, Ry contains a 64-bit word to be 
used in the compare, and Rz contains the length of the string in bytes. 
If string 1 <rel> constant is true, then the relative branch is taken. 
The final compare may be less than a word, i.e., the string need not be 
a multiple of eight bytes in length. Thus, this instruction appears to 
truncate on byte boundaries, if necessary, the word constant on the 
final compare to conform to the length of the string. 

This instruction has an appendage identical in format to the integer 
CMP. BR instructions. 



Opcode assignment j Code 



Implementation 
[Rx:<st>] <rel> Ry, Rz:<len>, branch 



CMPB. BR. CONST 



D01 



Special Notes: 

The contents of Rx and Rz are unpredictable at the end of the 
instruction. If defined values for these registers are desired, use a 
software loop instead of these instructions. 



The format for the non-generalized CMPB . BR . CONST instruction is 



D J I 1 I x I y J z |ccdj 12-bit disp| 



Opcode 



12-bit PC rel displacement 



Condition code descriptor 



Rz has length of string 1 in bytes 



Ry has comparison word 



Rx has address of string 1 



Instruction Specific Exceptions: none 
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10.3.3 CMPB.TEST Compare Byte Strings and Generate Test Result 

Compare, byte-wise, two strings of equal length. Rx contains the 
starting address of string 1, Ry the starting address of string 2, and 
Rz contains the length of the strings in bytes. The first inequality 
of the byte-wise compare, or, if equal, the exhaustion of the string, 
will set Rx to one of three values: 

If [Rx]:<st> less than [Ry]:<st> then set Rx to -1 
If [Rx]:<st> equal to [Ry]:<st> then set Rx to 
If [Rx]:<st> greater than [Ry]:<st> then set Rx to 1 



| Opcode assignment [ Code ] Implementation I 

! CMPB.TEST I 705 | [Rx]:<st> <rel> [Ry]:<st>, Rz:<len> \ 



Special Notes: 

The contents of Ry and Rz are unpredictable at the end of the 
instruction. If defined values for these registers are desired, use a 
software loop instead of these instructions. 



The format for the non-generalized CMPB.TEST instruction is 

'!7; ; 5 !x:y!z: 



I I. 

I 

I 



Rz has length of strings in bytes 



Ry has address of string 2 



Rx has address of string 1 



Opcode 



Instruction Specific Exceptions: none 
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11 DATA CONVERSION INSTRUCTIONS 

These instructions allow conversion across data types, including Double 
precision, Extended Double precision, Single precision, 64-bit signed 
Integer and ASCII numeric strings. 



CVT.AI 
CVT.DE 
CVT.DI 
CVT.DS 
CVT.ED 
CVT.EI 
CVT.ES 
CVT.IA 
CVT.ID 
CVT.IE 
CVT.IS 
CVT.SD 
CVT.SE 
CVT.SI 



Convert 


ASCII 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 


Convert 


from 



String to Integer 
Double to Extended 
Double to Integer 
Double to Single 
Extended to Double 
Extended to Integer 
Extended to Single 
Integer to ASCII 
Integer to Double 
Integer to Extended 
Integer to Single 
Single to Double 
Single to Extended 
Single to Integer 



FINP.32 
FINP.64 
FINP.80 



Floating Point Integer Part 
Floating Point integer Part 
Floating Point Integer Part 



Given the numerical attributes in the operand, the table below shows 
the expected result of a conversion for each instruction. 
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Table ll-l. Data Conversion Result Matrix for Operand States 



] Opcode 


Zero 


Denorm 


Normal 


Infinity 


QNaN 


SNaN 


| CVT.DE 


2 


4 


3 


5 


8 


6 


1 CVT.DI 


1 


1 


7 


6 


6 


6 


! CVT.DS 


2 


9 


3 


5 


10 


6 


J CVT.ED 


2 


9 


3 


5 


10 


6 


! CVT.EI 


1 


1 


7 


6 


6 


6 


] CVT.ES 


2 


9 


3 


5 


10 


6 


! CVT.ID 


12 


12 


12 


12 


12 


12 


1 CVT . IE 


13 


13 


13 


13 


13 


13 


i CVT. IS 


12 


12 


12 


12 


12 


12 


| CVT.SD 


2 


4 


3 


5 


8 


6 


1 CVT.SE 


2 


4 


3 


5 


8 


6 


| CVT. SI 


1 


1 


7 


6 


6 


6 


1 FINP.32 


2 


11 


11 


6 


6 


6 


| FINP.64 


2 


11 


11 


6 


6 


6 


! FINP.80 


2 


11 


11 


6 


6 


6 



CONVERSION RESULT: 

[I] Zero 

[2] Zero with same sign 

[3] Equivalent number 

[4] Equivalent normalized number 

[5] Infinity with same sign 

[6] Floating Point Invalid Operation 

[7] Truncated number 

[8] Same Quiet NaN with zeroes appended to significand 

[9] Floating Point Underflow 

[10] Same Quiet NaN with least significant bits truncated 

[II] Rounded to Floating Point Integer 
[12] Rounded result 

[13] Exact result 

Using, for an example, the instruction CVT.DE (Convert Double to 

Extended) , assume 



If operand to be converted is a denormalized number, then the 
conversion result in the destination operand will be an equivalent 
normalized number. This is conversion result (4) above. 

If operand to be converted is a signaling NaN, then no conversion 
takes place; rather, a FLOATING POINT INVALID OPERATION exception 
is generated. This is conversion result (6) above. 
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Note that CVT floating to Integer instructions truncate, while CVT 
floating to floating instructions obey the rounding mode. However, the 
FINP instructions may be used to round floating point numbers to 
Integer in the same floating point format. The instruction sequence 

FINP. 32 
CVT. SI 

will round a floating point number as it is converted to Integer. 



11.1 ASCII CONVERSION INSTRUCTIONS 

These instructions perform conversions on 64-bit signed Integers and 
numeric strings. A numeric string is a sequence of ASCII encoded 
numbers within the set ['30' ..'39' 1 hex. 

CVT.AI replaces Rx with the conversion of Rz from an eight digit 
numeric string to a 64-bit signed Integer. Results are unpredictable 
if a byte in the numeric string is not hex '00' or hex '30' to '39'. 

CVT.IA replaces Rx with the conversion of Rz from a 64-bit signed 
Integer to an eight digit numeric string. Results are unpredictable if 
the operand is outside the range through 99,999,999. 



11.1.1 CVT.IA Convert from Integer to ASCII 

11.1.2 CVT.AI Convert from ASCII to Integer 



] Opcode assignment | Code ] Implementation ] 

I CVT.AI I 70C I Rx <- Rz converted J 

; CVT.IA ; 70D I Rx <- Rz converted \ 
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The formats of these non-generalized instructions are 



7 





c 


' x ' 


i 

i 


2 ! 


A . 




A 


A 

1 
1 
1 
1 
1 
1 




A 




1 
1 

1 
1 
1 
1 




: i 






7 


o 


D 


1 X ' 

1 x 1 


i 
— i 


z ; 


A 




A 


A 

1 
1 
1 

1 

1 

pcode 


Rx 


A 




1 





! i 




recei' 



CVT.AI instruction 



Rz has the numeric string to convert 



CVT.IA instruction 



Rz has 64-bit Integer to convert 



Instruction Specific Exceptions: none 



11.2 CONVERT FROM DOUBLE TO EXTENDED, INTEGER, OR SINGLE 

Convert 'Last Operand' from Double to Double Extended (CVT.DE) , 64-bit 
Integer (CVT.DI), or Floating Point Single (CVT.DS). Place the result 
into Operand 1. 



11.2.1 CVT.DE 

11.2.2 CVT.DI 

11.2.3 CVT.DS 



Convert from Double to Extended 
Convert from Double to Integer 
Convert from Double to Single 





Opcode 














1 CVT.DE 


CVT.DI 


CVT.DS J 


Implementation 








| 3D7 


3D3 


3D6 | 


Rx(,Rx+l) <- 


RZ 






converted 


| 4D7 


4D3 


4D6 j 


Rx(,Rx+l) <- 


e(l6} 






converted 


S 6D7 


6D3 


6D6 I 


Rx(,Rx+l) <- 


e{32} 






converted 


J BD7 


BD3 


BD6 


Rx(,Rx+l) <- 


[Rz] 






converted 


S CD7 


CD3 


CD6 j 


Rx(,Rx+l) <- 


[Ry]e 


{12} 




converted 


\ DD7 


DD3 


DD6 j 


Rx(,Rx+l) <- 


[Ry][Rz]e 


{32} 


converted 


\ ED7 


ED3 


ED6 


Rx(,Rx+l) <- 


[Ry][Rz]e 


{32} 


converted 


| FD7 


FD3 


FD6 J 


Rx(,Rx+l) <- 


[Rz]e 


{32} 




converted 
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Instruction Specific Exceptions: 



I EXCEPTION | 


CVT.DE 


CVT.DI 


CVT.DS 


! FP Underflow | 






X 


J FP Overflow j 






X 


J FP Invalid Operation | 


X 


X 


X 


] FP Inexact Result J 






X 


| Integer Overflow \ 




X 





11.3 CONVERT FROM EXTENDED TO DOUBLE, INTEGER, OR SINGLE 

Convert 'Last Operand' from Extended to Double (CVT.ED) , 64-bit Integer 
(CVT.EI), or Floating Point Single (CVT.ES) . Place the result into 
Operand 1. 



11.3.1 CVT.ED Convert from Extended to Double 

11.3.2 CVT.EI Convert from Extended to Integer 

11.3.3 CVT.ES Convert from Extended to Single 



| Opcode assignment ] Code \ Implementation , 

CVT.ED | F07 J Rx <- Rz,Rz+l converted j 



! CVT.EI J F03 , Rx <- Rz,Rz+l converted 
! CVT.ES ] F06 | Rx <- Rz,Rz+l converted 
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The formats of these non-generalized instructions are 



CVT.ED instruction 



Rz,Rz+l has Double Extended source 



Rx receives the Double precision number 



iFiolslxl-lzl 



CVT.EI instruction 



_Rz,Rz+l has Double Extended source 



_Rx receives the Integer 



CVT.ES instruction 



_Opcode 



Rz,Rz+l has Double Extended source 



Rx receives the Single precision number 



Instruction Specific Exceptions: 



EXCEPTION 



CVT.ED 



CVT.EI 



CVT.ES 



FP Underflow 

FP Overflow 

FP Invalid Operation 

FP Inexact Result 

Integer Overflow 



X 




X 


X 




X 


X 
X 


X 


X 
X 




X 
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11.4 CONVERT FROM INTEGER TO DOUBLE, SINGLE, OR EXTENDED 

Convert 'Last Operand' from 64-bit signed Integer to Double (CVT.ID), 
Floating Point Single (CVT.IS), or Extended (CVT.IE). Place the result 
into Operand 1. 



11.4.1 CVT.ID 

11.4.2 CVT.IS 

11.4.3 CVT.IE 



Convert from Integer to Double 
Convert from Integer to Single 
Convert from Integer to Extended 









CVT.ID 


CVT.IS 


\ Implementation 




3D2 


3C2 


\ RX <- Rz 


converted 


4D2 


4C2 


\ Rx <- e{l6> 


converted 


6D2 


6C2 


; Rx <- e{32) 


converted 


BD2 


BC2 


| Rx <- [Rz] 


converted 


CD2 


CC2 


! Rx <- [Ry][Rz] 


converted 


DD2 


DC2 


! Rx <- [Ry]e{l2> 


converted 


ED2 


EC2 


! Rx <- [Ry][Rz]e{32] 


converted 


FD2 


FC2 


\ Rx <- [Rz]e{32> 


converted 



! Opcode assignment [ Code ] Implementation 

| CVT.IE ! F02 [ Rx,Rx+l <- Rz converted 



The format of the non-generalized CVT.IE instruction is 



F ! I 2 I x | 



1 z ' 



CVT.IE instruction 



Opcode 



Rz contains the Integer source 



Rx, Rx+1 receive the Extended conversion 
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Instruction Specific Exceptions: 



EXCEPTION 



CVT-ID 



CVT.IE 



CVT.IS 
X 



FP Inexact Result 



11.5 CONVERT FROM SINGLE TO DOUBLE, INTEGER, OR EXTENDED 

Convert 'Last Operand 1 from Floating Point Single to Double (CVT.SD), 
64-bit Integer (CVT.SI), or Extended (CVT.SE). Place the result into 
Operand 1. 



11.5.1 CVT.SD 

11.5.2 CVT.SI 

11.5.3 CVT.SE 



Convert from Single to Double 
Convert from Single to Integer 
Convert from Single to Extended 



| CVT.SD 


Opcode 
CVT.SI 


CVT.SE | 


Implementation 






| 3C6 


3C3 


3C7 1 


(Rx,Rx+l) <- 


RZ 




converted 


1 4C6 


4C3 


4C7 ! 


(Rx,Rx+l) <- 


e{l6> 




converted 


I 6C6 


6C3 


6C7 ; 


(RX,Rx+l) <- 


e{32} 




converted 


| BC6 


BC3 


BC7 1 


(Rx,Rx+l) <- 


[Rz] 




converted 


! CC6 


CC3 


CC7 j 


(RX,RX+1) <- 


[Ry][Rz] 


converted 


] DC6 


DC3 


DC7 \ 


(Rx,Rx+l) <- 


[Ry]e 


{12} 


converted 


| EC6 


EC3 


ec7 ; 


(RX,RX+1) <- 


[Ry][Rz]e{32} 


converted 


] FC6 


FC3 


fc7 ; 


(Rx,Rx+l) <- 


[Rz]e 


{32} 


converted 



Instruction Specific Exceptions: 



EXCEPTION 



CVT.SD 
X 



CVT.SE 
X 



CVT.SI 



FP Invalid Operation 
Integer Overflow 



X 
X 
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11.6 FINP FLOATING POINT INTEGER PART 

With the two operand forms, Operand 2 is rounded at the binary point 
based on the rounding mode, and the resulting floating point Integer 
replaces Operand 1. With the three operand forms, Operand 3 is the 
source and Operand 2 is ignored. 



Opcode 








1 FINP. 32 


FINP. 64 




Implementation 


1 3CF 


3DF 


! Rx <- 


Integer part of Rz 


! 4CF 


4DF 


! Rx <- 


Integer part of e{l6) 


! 6CF 


6DF 


' Rx <- 


Integer part of e{32} 


1 BCF 


BDF 


! Rx <- 


Integer part of [Rz] 


; CCF 


CDF 


! Rx <- 


Integer part of [Rz] 


1 DCF 


DDF 


! Rx <- 


Integer part of e{l2} 


\ ECF 


EDF 


! Rx <- 


Integer part of [Rz]e{32} 


\ FCF 


FDF 


! Rx <- 


Integer part of [Rz]e{32} 



Opcode assignment j Code 
FINP. 80 ! FOF 



Implementation , 

(Rx,Rx+l) <- Integer part of (Rz,Rz+l) J 



The format of the non-generalized FINP. 80 instruction is 



! F ! x ! 



Opcode 



Rz, Rz+1 is source operand 



Rx, Rx+1 is result operand 



Instruction Specific Exceptions: 



FLOATING POINT INVALID OPERATION 
FLOATING POINT INEXACT RESULT 



RESULT MATRIX FOR FINP 



If OP1 is 



then result is 



Zero 

Denorm , Normal 

Infinite 



Zero. The sign of the operand is preserved. 

Computed 

Invalid Operation 
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12 FLOW OF CONTROL INSTRUCTIONS 

The control instructions may be divided into 4 basic groups: simple 
control transfer, conditional control transfer, procedural control 
transfer and control transfers requiring special handling. 

In all control instructions (including the compare and branch 
instructions) , any relative offsets refer to the first byte of the 
instruction. 



Simple Control Transfer Instructions 

BR.ABS Branch Absolute 

BR.REL Branch Relative 

BR. BACKWARD Branch Backward Short Relative 

BR. FORWARD Branch Forward Short Relative 



Conditional Control Transfer Instructions 

BR.<cond>.ABS Branch Register Conditional absolute 

BR.<cond>.REL Branch Register Conditional relative 

BR.B <cond>.SH REL Branch Backward Register conditional 

BR.F <cond>.SH REL Branch Forward Register conditional 



Procedural Control Transfer Instructions 

BR. REG Branch through Register 

CALL Procedure Call Through Stack 

CALL. REG Procedure Call Through Register 
EXIT 



Control Transfers Requiring Special Handling 

BREAKPOINT 

EXCEPTION 

IXIT Exit from Interrupt 

BXIT Exit from Break 



12.1 UNCONDITIONAL BRANCHES 

BR.ABS loads the program counter with the 32-bit displacement encoded 
in the instruction. 

BR.REL adds the 32-bit signed integer offset encoded in the instruction 
to the program counter. 
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BR. BACKWARD subtracts the unsigned 8-bit displacement from the program 
counter. The branch range is from to -255 bytes. 

BR. FORWARD adds the unsigned 8-bit displacement to the program counter. 
The branch range is from to 255 bytes. 



12.1.1 BR.ABS Branch Absolute 

12.1.2 BR.REL Branch Relative 

12.1.3 BR. BACKWARD Branch Backward Short Relative 

12.1.4 BR. FORWARD Branch Forward Short Relative 



] Opcode assignment [ Code 



Implementation 



BR.ABS 
BR.REL 
BR. BACKWARD 
BR. FORWARD 



E07 
EOF 
AOx 
20x 



PC <- displacement 

PC <- PC + displacement 

PC <- PC - unsigned displacement 

PC <- PC + unsigned displacement 



The formats for these instructions are 



E | |OP2| - | - 



<32-bit displacement 



OP 2 code 



OP1 code for non-generalized instructions 



OPO code 



|OP0| |<displ>; 



Short Unconditional Branch format 



i i 
i i. 
i 



8-bit unsigned displacement 



OP1 code for non-generalized instructions 



OPO code 



Instruction Specific Exceptions: none 
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12.2 BRANCH REGISTER CONDITIONAL LONG INSTRUCTIONS 

Load (BR.<COND>.ABS) or add (BR.<COND>.REL) the 32-bit signed integer 
encoded in the instruction to the program counter if the relation 
[(register) <cond> zero] is true. 



12.2.1 BR.<cond>.ABS 

12.2.2 BR.<cond>.REL 



Branch Register Conditional Absolute 
Branch Register Conditional Relative 



Opcode assignment | Code 



Implementation 



BR.GT.ABS 
BR.EQ.ABS 
BR.GE.ABS 
BR.LT.ABS 
BR.NE.ABS 
BR.LE.ABS 



E01 ! PC <- signed disp, 

E02 J PC <- signed disp, 

E03 ! PC <- signed disp, 

E04 ] PC <- signed disp, 

E05 [ PC <- signed disp, 

E06 ! PC <- signed disp, 



Rx<GT>0 
Rx<EQ>0 
Rx<GE>0 
Rx<LT>0 
Rx<NE>0 
Rx<LE>0 



Opcode assignment , Code 



Implementation 



BR.GT.REL 
BR.EQ.REL 
BR.GE.REL 
BR.LT.REL 
BR.NE.REL 
BR.LE.REL 



E09 
EOA 
EOB 
EOC 
EOD 
EOE 



PC <- PC+signed disp, Rx<GT>0 

PC <- PC+signed disp, Rx<EQ>0 

PC <- PC+signed disp, Rx<GE>0 

PC <- PC+signed disp, Rx<LT>0 

PC <- PC+signed disp, Rx<NE>0 

PC <- PC+signed disp, Rx<LE>0 



The instruction format for the long conditional branches is 



! E ! !0P2l x ! 



<32-bit displacement 



i i i 
i i. 

i 

i 



Rx register to test 



Sub-op code 



OPO 



OP1 code for non-generalized instructions 



Instruction Specific Exceptions: none 
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12.3 BRANCH REGISTER CONDITIONAL SHORT RELATIVE INSTRUCTIONS 

Subtract (BR.B.<cond>.SH.REL) or add (BR.F.<cond>.SH.REL) the 8-bit 
unsigned integer encoded in the instruction to the program counter if 
the relation [(register) <cond> zero] is true. 



12.3.1 BR.B.<cond>.SH.REL Branch Backward Register Conditional 

Short Relative 

12.3.2 BR.F.<cond>.SH.REL Branch Forward Register Conditional 

Short Relative 



Opcode assignment ] Code 



Implementation 



BR.B.GT.SH.REL 
BR.B.EQ.SH.REL 
BR.B.GE.SH.REL 
BR.B.LT.SH.REL 
BR.B.NE.SH.REL 



B09 [ PC <- PC-unsigned disp, Rx<GT>0 

BOA j PC <- PC-unsigned disp, Rx<EQ>0 

BOB ] PC <- PC-unsigned disp, Rx<GE>0 

BOC j PC <- PC-unsigned disp, Rx<LT>0 

BOD j PC <- PC-unsigned disp, Rx<NE>0 

BOE ] PC <- PC-unsigned disp, Rx<LE>0 



Opcode assignment , Code 



Implementation 



BR.F.GT.SH.REL 
BR.F.EQ.SH.REL 
BR.F.GE.SH.REL 
BR.F.LT.SH.REL 
BR.F.NE.SH.REL 
BR.F.LE.SH.REL 



309 
30A 
3 OB 
30C 
30D 
30E 



PC <- PC+unsigned disp, Rx<GT>0. 
PC <- PC+unsigned disp, Rx<EQ>0 
PC <- PC+unsigned disp, Rx<GE>0 
PC <- PC+unsigned disp, Rx<LT>0 
PC <- PC+unsigned disp, Rx<NE>0 
PC <- PC+unsigned disp, Rx<LE>0 
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The instruction format for the short conditional branches is 



|OPOJ !0P2| X K<3ispl>; 



A___A 



8-bit unsigned displacement 



Rx register to test 



0P2 code 



0P1 code for non-generalized instructions 



_OP0 = 3 for BR.F.<cond>.SH.REL 
OPO = B for BR.B.<cond>.SH.REL 



Instruction Specific Exceptions: none 



12.4 PROCEDURAL CONTROL TRANSFER INSTRUCTIONS 

There are two types of procedure calls supported by the ELXSI 
architecture. Their difference lies in where the return Program 
Counter value is saved (the address of the instruction immediately 
following the call) , and by the architectural support provided for 
local stack frame deallocation. 

In the first and most commonly used type, the return PC value of the 
calling procedure is placed (rather than pushed) in the 32-bit memory 
location pointed at by the stack pointer (CALL) . When returning from 
the called procedure, the local stack frame is deallocated 
automatically, restoring the return PC value (EXIT) . 

In the alternate procedure call mechanism, the return PC is passed in a 
register (CALL. REG). To return to the calling procedure, a branch 
through register is executed (BR. REG) . No architectural stack frame 
deallocation support is provided for the CALL. REG and BR. REG 
instructions. Any local stack frame handling must be done by specially 
emitted code. 



For a complete description of the procedure calling 
reader should refer to Section 2.3, "Procedure Calls". 



mechanism, the 



Procedural Control Transfer Instructions 



BR. REG 
CALL 
CALL. REG 
EXIT 



Branch through Register 
Procedure Call Through Stack 
Procedure Call Through Register 
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12.4.1 BR. REG Branch through Register 

Load the program counter from the specified register. 



J Opcode assignment | Code 



Implementation 
PC <- Rx 



BR. REG 



600 



Instruction Specific Exceptions: none 

Special Notes: 

This instruction is used in conjunction with the CALL. REG instruction 
to return from a procedure call. 

The format of the non-generalized BR. REG instruction is 



6 | | |Rx J 



Load PC with the address in Rx 



Opcode 



12.4.2 CALL Procedure Call Through Stack 

The CALL instruction places the return PC (as an absolute address) into 
the 32-bit memory location pointed at by register 15 (the stack 
pointer) and branches absolute to the 32-bit signed integer address 
encoded in the instruction. 



J Opcode assignment ] Code 



Implementation 

[R15] <- PC+7, PC <- signed disp 



CALL 



E00 
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The format of the non-generalized CALL instruction is 



: e : o ; o i 



<32-bit address> 



Opcode 



Instruction Specific Exceptions: none 



12.4.3 CALL. REG Procedure Call Through Register 

The CALL. REG instruction places the return PC value (as an absolute 
address) into the specified register and branches absolute to the 
32-bit signed integer address encoded in the instruction. 



Opcode assignment ] Code 



Implementation 

Rx <- PC+7, PC <- signed disp 



CALL. REG 



E08 



The format of the non-generalized CALL. REG instruction is 



! E ! ! 8 !rx ! 



- [ - ! <32-bit address> [ 
Return PC is placed in register Rx 



Opcode 



This instruction may also be used to place the current PC into a 
specified register. Execute a CALL. REG with the address of the next 
instruction as the destination of the call. This function may also be 
accomplished with the LD.64 instruction and the help of the binder. 



Instruction Specific Exceptions: none 
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12.4.4 EXIT 

The EXIT instruction deallocates the local stack frame or activation 
record. It adds an unsigned 8-bit displacement to the stack pointer, 
then places the absolute address from the new top-of-stack into the PC. 
The displacement, encoded in the instruction, represents the distance 
from the current stack pointer to the return PC location in the stack. 



i Opcode assignment j Code | Implementation j 

! EXIT 1 300 I SP <- SP + udisp, PC <- [SP] J 

The format of the non-generalized EXIT instruction is 
Byte -0- -1- -2- 

; 3 ; o ; o | - !<dis P i>; 



i 8-bit unsigned value to add to SP 

Opcode 



EXIT and CALL instructions both assume stack storage for the PC return 
values, and should be paired likewise. If using a CALL. REG 
instruction, return through a branch register instruction, and perform 
local stack frame handling by an add to the SP. 

Slightly different code is usually emitted when the stack frame 
contains dynamic arrays or arrays larger than 2**8 bytes. 



12.5 CONTROL TRANSFERS REQUIRING SPECIAL HANDLING 

For a more complete description of exception handling, see Chapter 2, 
"Architecture" . 



12.5.1 BREAKPOINT 

The BREAKPOINT instruction pushes the next instruction address and 
registers RF through R0 onto the stack, loads registers R0 through R4 
with specific information, and loads the PC with a prespecified entry 
point into the system Debugger. See Section 2.4, "Interrupts and 
Breakpoints", for a complete description of the data placed in the 
registers. 
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Opcode assignment [ Code ] Implementation 



| BREAKPOINT | 10 J see above description j 



The format of the non-generalized BREAKPOINT instruction is 

1 l ' o ' 
i x i u i 

A A 

j Opcode. This is a one-byte instruction 



Instruction Specific Exceptions: none 



12.5.2 EXCEPTION 



Sends a Software Generated Exception class message which includes the 
concatenated 64-bit values of Rx and Rz. Rx forms the high order 64 
bits and Rz forms the low order 64 bits. 



i 



Opcode assignment \ Code J Implementation 



! EXCEPTION [ 000 ', see above description 



The format of the non-generalized EXCEPTION instruction is 



;o|OJOix!-|z! EXCEPTION instruction 



! J Rz contains second message value 

i 
i 

j R x contains first message value 



Opcode 
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12.5.3 IXIT Exit from Interrupt 

The IXIT instruction is used to exit from an interrupt routine. First, 
the local stack frame is deallocated by adding an unsigned 8-bit 
displacement to the stack pointer. The data in the stack belonging to 
the interrupted routine is then restored and deallocated from the 
stack, returning control to the interrupted routine. At the completion 
of this instruction, the process's local priority will have been 
restored to its old saved value, or to the highest priority active 
channel, whichever is higher. 

Interrupts push data into the stack in the following order: the next 
instruction address (as a 64-bit value) , the local priority of the 
interrupted process (as a 64-bit value) , and registers RF through RO. 
See Section 2.4, "Interrupts and Breakponts", for a complete 
description of the data placed in the stack. 



12.5.4 BXIT Exit from Break 

The BXIT instruction is used to exit from a routine entered through a 
BREAKPOINT instruction or by a single step break (usually a Debugger, 
action) . The contents of register RO determines whether or not single 
stepping is enabled. If RO = 0, then single stepping is disabled. If 
RO = 1, then single stepping is enabled. The only other difference 
between the IXIT and BXIT instructions lies in the absence of the local 
priority on the stack if the routine entered is the result of a 
BREAKPOINT (RO = 0) . 



| Opcode assignment | Code J Implementation ] 

I IXIT J 301 ] see above description [ 

! BXIT ] 302 ] see above description i 
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The formats for these instructions are 

Byte -0- -1- -2- 

I 3 J ! 1 ! - !<displ>! IXIT instruction 



I 3 | | 2 | - |<displ>j BXIT instruction 

A A A A 

j | Add 8-bit unsigned value to SP 

i 
i 
] Opcode 



Slightly different code is usually emitted when the stack contains 
dynamic arrays or arrays larger than 2**8 bytes. 
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13 INTER-PROCESS COMMUNICATIONS 

A structural- view of the ELXSI multiprocessor environment is that of 
time and location independent processes executing concurrently and 
communicating only through messages. 

This chapter provides an introduction to the message system. Chapter 

14 provides the details of the message system instructions. EMBOS 
Programmer's Reference Manual , Volume 3, introduces the concepts of job 
and process structures and provides a lower level detail of the message 
system. 



13.1 MESSAGE SYSTEM OVERVIEW 

The message system serves as the intelligent medium through which 
messages are sent. Following are some of the communication attributes 
in the message system environment: 



o Process Concurrence. The communication structures that enable 
messages to be sent and received are created through a protocol 
that requires the participation and agreement of both processes. 

o Transparency. A process may send or receive a message from any 
participating process (including itself) where the communication 
path exists to transfer the message. The message system allows 
the communication to be asynchronous through the provision of a 
message buffer; j thus, messages may be queued until the 
receiving process is ready to bring the message into its process 
space. The message system makes no modifications to any data 
sent between processes. 

o Process Substitution. A sending process need not be aware of 
the physical location or even the real identity of a receiving 
process. This allows the operating system to substitute 
processes to allow, for example, I/O redirection from a spooling 
process. 

o Communication Security. All processes are bounded by their 
32-bit virtual address space. Security and reliability of the 
system are enhanced as the communication attributes of a process 
are enforced through hardware protection. This has the 
advantages of hiding the data structures and implementation 
details of a given process from other processes, and of 
providing firewall protection. 

The assignment of communication links between processes is done 
on a "need to know" basis. Each process is responsible for 
controlling the incoming communication paths to itself. It does 
this by providing these communication paths only to those 
processes that must send messages to it. Consequently, with the 
distribution of communication paths managed in this way, each 
process is only given the communication paths to those processes 
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that it needs to send messages to. This scheme restricts the 
range of outside processes that any one process can communicate 
with, and it is not within the power of that process to expand 
this range (since no process is allowed to alter the tables that 
control its outgoing communication paths to other processes or 
the tables that control the handling of incoming messages from 
other processes) . The only way it can expand this range is with 
the cooperation of the process that will be the recipient of its 
messages. 

Many system security problems can be traced to malicious 
processes that have been able to forge their identities. With 
the ELXSI system, every message sent is tagged by the firmware 
with the process ID of the sender. The sender has no way of 
altering the process ID tag in the message, and it cannot alter 
the location that the firmware uses as the source of the process 
ID because this location is not even in the sender's address 
space. Consequently, the sender has no way to forge the process 
ID tag in the message, and the receiver can be assured that the 
sender's process ID is authentic. 

o No Privileged mode. There is no privileged instruction mode in 
the ELXSI system. The process address space map, which controls 
access to memory, and the process link table, which controls 
access to the processes that manage other system resources, both 
reside outside any user's address space. Because user access to 
system address space, system processes, and system resources is 
so restricted, no privileged instruction mode is needed. 



13.1.1 Communication Structures 

The communication structure of a process consists of links, funnels, 
and channels and the tables that they reside in. These tables are all 
located outside the user process address space, and are not modifiable 
by the user. The user, however, has read access, via instructions, to 
the link and funnel tables and can look at individual link and funnel 
table entries. Only the firmware can write into these tables, and it 
is capable of adding or deleting table entries or of modifying fields 
within each of the entries. 

Links are the address pointers over which messages are sent. As such, 
they generally point to outside processes, although they can also point 
to this process since a process can also send messages to itself. Each 
link corresponds to a single pointer and contains the process ID and 
version ID of the target process and the ID of the funnel that is to 
get the message. The funnel resides on the target process and is the 
mailbox slot into which the message goes when it is sent. Each funnel 
corresponds to a single mailbox slot and contains the channel that it 
is attached to and the head and tail pointers to the list of messages 
that have been delivered into this funnel, but not yet received (with 
the Receive instruction) by the target process. The channel that the 
funnel is tied to provides it with attributes that are essential to the 
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interrupt system used to modify the instruction execution flow for this 
process (when interrupting conditions occur) and the priority system 
used to schedule and allocate system resources for this process 
vis-a-vis other active processes on this particular processor. Each of 
these three basic elements of a process's communication structure is 
described in more detail below. 



13.1.1.1 Links 

Links serve as address pointers for the routing of messages in the 
message system. They are used by sending processes to direct messages 
into the funnels of target processes. 

Links are composed of two basic elements: a data structure known as 
the link table entry (LTE) , and an index into the link table entry 
known as the link ID. 

Within the LTE is information on the link attributes, the process ID of 
the link creator, and the funnel of the link creator that will receive 
the messages. The link creator is the process that has created the 
link to enable it to receive messages from other processes. 

The link creator passes or copies the link to the link holder, that is, 
the process from which the link creator wishes to receive messages. 
The link is passed or copied by sending the LTE information in a 
message. When the process receives the message, the incoming LTE 
information is placed into the link table of that process. The link ID 
specified by the receiver of the message is the index into the link 
table entry location for placement of the incoming LTE. 

When the link holder wishes to send a message, the link ID of the link 
is incorporated as a parameter in the message. This link ID points to 
the LTE for that link, which in turn points to the location of the 
process that is to receive the message. 

There may be up to 65,535 links for each process. A link must always 
be directed into exactly one funnel. 

The link creator may specify other attributes of the link, including 
the rights of a link holder to copy or pass the link to another 
process, the right to receive notification if the link holder copies, 
passes, or deletes the link, and other attributes as specified in the 
link table data structure. If a link is copied, an additional link is 
directed into the funnel of the link creator, thus several processes 
may hold copies of the link, all directed into the same funnel. 
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13.1.1.2 Funnels 

Funnels serve essentially as input ports through which a process- may 
receive messages. The funnel ID is specified in the link entries for 
all of the links that are directed into the funnel. A process may have 
a total of 255 funnels, all of which may be attached to a given 
channel. Each funnel has an associated interrupt vector to allow an 
interrupt to be taken to an interrupt handling procedure if the channel 
to which the funnel is attached is enabled for interrupts. The 
interrupt is generated when a message arrives on a funnel attached to a 
channel which has interrupts enabled. 

Messages are received on funnels in FIFO order. However, funnels 
attached to a given channel essentially have the same priority among 
themselves. The priority of the channel to which a funnel is attached 
determines the funnel's priority, and thus the priority of any messages 
arriving on a funnel attached to that channel. 

Any number of links may be directed into a funnel. Funnels must at all 
times be attached to a channel, but may be moved to another channel if 
desired. 



13.1.1.3 Channels 

Each process has 16 channels, numbered to 15, and each channel has an 
associated local priority that is the same as the channel number. The 
highest priority channel is channel 0, with the priority decreasing 
monotonically. 

The channel priority map belonging to a process specifies a global 
priority associated with its local priority. This global priority is 
the process priority for that channel relative to other processes. 

Channels can be interruptable. When a message arrives on a funnel 
attached to a channel that has interrupts enabled, and that channel is 
the highest priority active channel, and its priority is higher than 
the currently executing code within the process, an interrupt is taken 
to the interrupt handler address specified by the funnel interrupt 
vector. 

An active channel is a channel that has one or more messages pending in 
one of its attached funnels. The local priority of a process is the 
channel ID of highest priority active channel. The arrival of a 
message may raise the local priority of a process but never lower it. 
Local process priority may be raised or lowered explicitly through an 
instruction provided for this purpose. 
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13.1.2 Message Composition 

There are several types of messages. In the most typical case, that of 
a "simple" message, the length of the data is variable, separable into 
two message blocks if desired, with a maximum total length of 888 
bytes. Messages may also contain links to be copied or passed from the 
sending process, or they may contain data to be forwarded to a tertiary 
process via an intermediate process. If a link is contained in a 
message, the remaining length of the message may extend up to 672 
bytes. 

Messages from a sending process are prepended by the firmware with the 
unforgeable process ID of the sending process. If the link to the 
receiving process is undefined, no message will be sent. 



13.2 MESSAGE SYSTEM OPERATIONS 

This section presents an overview of how communication paths are 
created between processes, and the general method through which 
messages are sent and received. 



13.2.1 Establishing a Communication Path 

A communication path must be established before any message may be sent 
or received. A process is conferred at birth with a certain number of 
links and funnels, known as standard links and standard funnels. These 
are discussed in the Programmer ' s Reference Manual , Volume 3. 

To create a link, a funnel must exist for the link to be directed into. 
The process then creates a link directed into its own funnel and then 
passes or copies the link to the requesting process. 

It is quite possible that a process (such as a spooler) might want 
communication in only one direction. The underlying principle of the 
message system is that processes communicate with each other by mutual 
consent according to some protocol they agree upon. The message system 
does not enforce some inherent protocol or synchronization. Rather, it 
is the manner in which the message system is used that can establish a 
protocol or synchronization. 



13.2.2 Sending Messages 

To send a message, the process first constructs a message in its data 
space that contains both the data to be sent and the link ID over which 
the message is to be sent. The data area containing the link ID is 
referred to as the "parameter block", and the data area immediately 
following as the "message block". When the process is ready to send 
the message, a SEND type instruction is invoked which copies the 
message from the sender's virtual address space into the system message 
buffer space. 
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The message system prepends, via firmware, the process ID of the 
sending process to the message. The message system firmware then 
performs the following: 

1. It looks up the corresponding link entry in the link table 
belonging to the sending process, for which the link ID is the 
index. If the link entry does not exist, an error message is 
returned to the sender and the message is not sent. Otherwise 
the message is copied from the user's virtual address space into 
a linked group of free system message buffers. 

2. Additional information is prepended to the message that 
specifies the type of message, the funnel ID, the number of 
bytes of data in the message, and other information depending on 
the type of message. This, along with the "from process ID", is 
encoded in a block of information known as "receive control 
information" . 

3. A Send Message Operation Bus Information Quantum (BIQ) pair is 
transmitted to notify the target process that an incoming 
message is pending for it. This BIQ-pair is fielded by the 
target unit • s Send Message Operation Handler in a procedure 
called "message delivery". This operation handler responds to 
the sending process with bad status if the message cannot be 
delivered or with good status if delivery can take place. 

4. Actual delivery of the message occurs when this operation 
handler attaches the message buffers containing the message to 
the funnel queue of the funnel specified in the sender's link 
table entry. At this point, the message continues to reside in 
the system message buffers until the target process executes a 
receive. 

The important thing to note here is that the SEND instruction transmits 
only the Send Message Operation BIQ-pair, essentially 2 GigaBus-width 
words, to the target process to notify it that there is a message 
pending for it. The BIQ-pair contains the destination funnel ID and a 
pointer to the message buffer string having the actual message, and 
this is the information that message delivery uses to attach the 
message buffers to the funnel queue of the target process. The SEND 
instruction does not have to transmit the entire message across the 
GigaBus. Instead, the target process only gets the message transferred 
to it's virtual address space when the target process executes the 
receive operation against the message. 
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The following diagram illustrates the send message action: 



Sending a Message 



! PROCESS "A" ' 



' code space ' 



SEND instruction 




variable 

length 
message data 



SEND parameter , \ 
block w/index ] 
to link table \l 



W 



\ MESSAGE SYSTEM 

\ Firmware 
-> finds correct 
/ receiving process 
from Link Table 
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\ 



/ 
i 
i 



Encode message 

with 
From Process ID 

Encode Receive 
Control Info. 

i 
v 

Place message in 
system message 
buffers. 



13.2.3 Receiving Messages 

To receive a simple message, a process issues the receive instruction, 
specifies the target virtual data space for the message, and constructs 
the accompanying parameter block that specifies how the receive is to 
operate. When the receive is executed, the message, along with the 
receive control information, is transferred from the system message 
buffers into the virtual address space of the receiving process. The 
process can receive a message on a specific funnel by issuing a Receive 
On Funnel instruction. This would be the kind of receive issued if an 
incoming message arrived on an interrupting channel because the 
interrupt handler would know which funnel the message arrived on. 
Alternatively, the process can scan with the Receive On Channel 
instruction, and then receive the message from the highest priority 
active channel selected in the channel mask specified for that 
instruction. To receive a message containing a link, the process can 
issue a Receive Link On Funnel or Receive Link On Channel. These 
instructions allow the process to designate a link table location for 
storing the link in the message, in addition to the other link 
parameters. 
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The receiving process also has the option of suspending itself until a 
message has arrived on a particular funnel or channel. This can be 
performed by specifying a receive type of synchronous as opposed to a 
receive type of asynchronous. A synchronous Receive On Funnel issued 
against a funnel with no messages on it will cause the process to be 
blocked until a message does arrive on that funnel. A synchronous 
Receive On Channel issued against an inactive channel will also cause 
the process to be suspended until a message is delivered on any funnel 
that is attached to that channel. 



Receiving a Message 
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13.3 DATA STRUCTURES 

The data structures provided in this section describe the link and 
funnel table entries and headers as well as data structures for 
messages. The parameter blocks are described in detail with the 
associated instructions in Chapter 14, "Message System Instructions". 



13.3.1 Message 

In general, a message consists of to N bytes of information called 
message data. The maximum value for N depends upon the particular type 
of message: 



Typical Form of Message in Transit 

> 

J 64 bits of Receive Control | Variable length message 

Instructions also exist for passing, copying, or forwarding links along 
with a message. The details of these different types of messages are 
discussed in Chapter 14. 

13.3.1.1 Message Types 

A simple message may contain from to 888 bytes of message data which 
may be organized into one or two blocks as the user may determine 
convenient. Note that 888 bytes is the maximum message data length 
regardless of the number of blocks used. 

A small message may contain from to 4 bytes of message data which 
must be organized into one block. 

A To Hardware message may contain from to 8 bytes of message data 
which must be organized into one block. 



13.3.1.2 Parameter Blocks 

Parameter blocks reside in the virtual address data space of a process 
and contain parameters for certain message system instructions. For a 
process that wishes to send a simple message, for example, the process 
constructs a parameter block containing the link ID. The message 
itself follows after the two words of the parameter block. 
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To illustrate usage, a simple message as represented in the virtual 
space of the sending process is shown below. The registers indicated 
are the entry parameters for a SEND instruction. The "link ID" 
identifies the link over which the message will be sent. 



Starting address of parameter block 

\ in virtual memory 

] Field lengths: 

v 

[Ry] — > ! unused J Link ID | Unused 16 bits 
Link ID 16 bits 

| unused j Unused 32 bits 

+ 

/] ! | 64 bits 

Rz — ] ] [ message data space, block 1 | 

A V I I I 

\ i i i 

; 

i 
i 

! Variable length, in bytes, of message data in block 1 



[Rt] — > 



message data space, block 2 
(optional) 



Starting address of message block 2 



!\ 
i i 



, , — Rv is variable 
|/ length of block 2 



The RCV instruction uses the two words in the parameter block to 
specify the funnel and the type of receive desired. The parameter 
block is specified by the receiving process at some location in its 
virtual address space. 



[Ry]->; Funnel ID (8) \ <unused> (8) 
; Preferred Link ID (16) 



Type rev (8) 



<unused> (8) 



<unused> (16) 



A typical message that has been received and placed in 
address space of the receiving process is shown below. 



the virtual 
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[Ry]-> 



RCV 
CTL 
INFO 



Rz— 



| Funnel ID (8) | <unused> (8) | Type rev (8) | <unused> (8) 


| Preferred Link ID (16) \ <unused> (16) 


1 Link Code (16) | Funnel ID (8) ! Msg type (8) 


| From Process ID (16) | Number of Bytes (16) 


| Variable length message data 
1 block 1 



[Rt]-> 



Rv— 



Variable length message data 
block 2 



The specific formats for the parameter blocks are given with each of 
the receive instructions. The above fields are defined as follows: 



Funnel ID 

This 8-bit integer field in the first word of the parameter block 
has meaning when the instruction is a Receive On Funnel. The field 
identifies the funnel from which to receive a message, if any. 

If the instruction is a Receive On Channel, the high order 16 bits 
of the first word (shown above as Funnel ID <8> and Unused <8» 
contain a channel mask, where bit corresponds to channel 0, bit 1 
to channel 1,..., bit 15 to channel 15. This field causes the 
firmware to attempt to receive a message on every channel that has 
its corresponding bit set in the channel mask. The firmware starts 
with the highest priority channel and searches downward from there. 
It completes the receive when it finds a channel with a message or 
stops if there are no messages on any of the selected channels. 
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Type of Receive 

This specifies one of three kinds of receive the user may execute. 
The boolean values occupy the low order 3 bits of the receive type 
field: 

o Synchronous - If there is no message in the specified funnel, 
the user is blocked until a message is delivered into the 
funnel. If synchronous is not specified and no message is 
found, the receive instruction completes normally, and execution 
proceeds to the next instruction in the instruction stream. 

o Interrogate - The message, if any, is copied into the user's 

virtual address space, but the message remains attached to the 

funnel. If there is no message, the action is controlled by the 
Synchronous state. 

o Dismiss - This option invokes an implicit SET. LOCAL. PRIORITY 

instruction that will set the local priority of the process to 

either 15 or that of the highest priority active channel, 
whichever is higher. 



Preferred Link ID 

This field is used when the instruction is a Receive Link On Funnel 
or a Receive Link On Channel. The value in this field identifies 
the link table entry location where the link in the message should 
be placed. If the value is zero, a default location is selected 
from the list of free link table entries in order to receive the 
link in the message. The actual link ID of the link selected is 
returned in this field at the end of the instruction. 

The registers specified in the above diagram are the input parameters 
for the receive type instructions and are used to place the message as 
described above into the address space of the receiving process. 

Note that the receiving process may select one or two data blocks, and 
may establish the lengths of either as desired, independently of the 
format of the message as it originally existed in the sender's address 
space. For example, even though the message existed as a single 
contiguous block in the sender's space, the receiver is free to specify 
one block to hold the parameter block data and another separate block 
to hold the message itself. Note, however, that the receive control 
information is always placed into the field following the receive 
parameter block specified by [Ry]. 
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13.3.1.3 Receive Control Information 

The firmware prepends 8 bytes of what is known as receive control 
information to the message when it is sent. This information is 
available to the receiving process and contains the link code of the 
link upon which the message was sent, the identification number of the 
funnel into which the message was delivered, the type of the message, 
the process identification number of the sender and the length of the 
message data in bytes. The receive control information is written by 
the firmware and is not forgeable by the the sender. 

Although the receive control information is the same for all messages 
received by a process, the first part of the parameter block is 
dependent on the type of receive instruction, and is specified 
accordingly in Chapter 14. 



Receive Control Information, message format 
First 32 bits of word 
! Link Code (16) J Funnel ID (8) J Msg type (8) j 



Second 32 bits of word 
From Process ID (16) | Number of Bytes (16) 



The Receive Control fields are defined as follows: 

Link Code 

This is an arbitrary value associated with the link over which the 
message was sent. The sending process is the holder of the link. 

Funnel ID 

This is the funnel into which the link is directed, and through 
which the message was received. 

Message Type 

This field characterizes the incoming messages. It is typically 
used for notifying a link creator when one of its links has been 
copied, passed, or deleted. The notification message is sent 
automatically by the system to the link creator when the 
appropriate notify attribute for the link entry has been selected. 
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This boolean field is defined as follows (bits through 2 are 
unused) : 

Small Message 

The message may contain up to 4 bytes of message data organized 
into one block. This is a special kind of send in which the 
receiving process allocates a message buffer for the message, 
rather than the sending process. Uses bit 3 of this field. 

Link Deleted 

This indicates to the receiving process that the sender has 
deleted a link created by the link creator. Uses bit 4 of this 
field. 

Link Copied 

This indicates to the receiving process (link creator) that a 
link has been copied. Uses bit 5 of this field 

Link Passed 

This indicates to the receiving process (link creator) that a 
link has been passed on to another process. Uses bit 6 of this 
field. 

Includes Link 

This indicates that the message contains a link. Uses bit 7 of 
this field. 

From Process ID 

This is the ID of the sending process encoded into the message 
by firmware. 

Number of bytes in message 

This is the length of the message data, not including the 
receive control information, in bytes. 

Notice that if the length of the message data is zero, the receive 
control information will still be sent to the receiving process. 



13.3.1.4 Notification 

In many situations, it is useful for the creator or owner of a link to 
know if that link has been copied, passed, or deleted by one or more of 
the other processes that hold the link. If the link creator sets the 
notify attributes in the Link Rights field, then the link creator will 
be notified when the link is passed, copied, or deleted via a 
notification message sent along the affected link. 

The instructions that copy links, pass links, or delete links are also 
the ones that generate the notification messages. Each of these 
instructions checks the notify attributes in the Link Rights field to 
determine if the notification should be sent. The notification is not 
sent if the corresponding attribute is not set, or if the link holder 
is also the link owner (It would not be useful for the link owner to 
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send a notification message to itself) . The contents of the link 
deleted notification message is simply the receive control information 
that is sent with all messages, with the link deleted attribute set in 
the message type field. The link copied and the link passed 
notifications also contain the receive control information with either 
the link copied or the link passed attribute set in the message type 
field, along with an additional field that identifies the process to 
which the link was copied or passed. 



Notification Message for Copy and Pass Link Instructions 



Link Code (16) 
From Process ID (16) 
To process ID (16) 



Funnel ID (8) | Msg type (8) 
Number of Bytes (16) 
<unused> (16) 



The fields in the notification message are defined below: 

Link Code 

This field specifies the link code of the link that was copied, 
passed, or deleted. Links are always directed into the funnel of 
the link creator. 

Funnel ID 

This field specifies the funnel into which the link is directed, 
and upon which the message is received. 

Message Type 

This field specifies through boolean values whether the link has 
been copied, passed, or deleted by the notifying process. 

From Process ID 

This field specifies the process ID that executed the instruction 
to copy, pass, or delete the link. 

Number of bytes 

The message block length "number of bytes" will be zero for delete 
link notification, and 2 for copy and pass link notification. This 
is because the To Process field is not sent on the delete link 
notification. 

To Process ID 

This field identifies the process which had the link copied or 
passed to it. This field, and the unused field following it, are 
not used for the delete link notification message. 
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13.3.2 Links 

The link creator has ultimate control over the link and can specify 
copy link rights, pass link rights, notification rights, or message 
rights. A process may have up to 65,535 links. This number may be 
restricted by the creator of the process. 



13.3.2.1 Link Table Entries 



A process can be a link owner and a link holder. Owned links are 
created by the link owner and point only into the funnels of the owning 
process. Consequently, the link owner is also sometimes called the 
link creator. Owned links are circular and always point back into the 
funnels of the owner process. The link owner can send a copy of a link 
it owns to another process by issuing a Copy Link or Pass Link 
instruction. The recipient of that link becomes the holder of the link 
and now has a path for sending messages to the link owner. 
Consequently, held links are always created by processes other than the 
link holder and point into the funnels of those other processes (which 
also happen to be the owners and the creators of these links) . They 
always point away from the holding process and are the communication 
"links" between that process and the owning processes. 

All of the links that belong to a process, whether they are owned or 
held, are stored in double-word-length packets called link table 
entries. These entries are organized into a link table, which contains 
a combination of defined link table entries and free link table 
entries. The defined link table entries are the ones that contain 
valid owned and held links. The free link table entries are those that 
are available for creating new links or for storing additional held 
links. These free entries are held together in a doubly linked list, 
for simplicity in adding or removing elements from this list. 

The link ID is used as an index to a particular entry in the link 
table. Links are identified by their corresponding link ID, such that 
link 1 has link ID 1, link 44 has link ID 44, and so on. Link ID for 
link is reserved and points to the header entry of the link table. 
This entry contains information about the rest of the link table, such 
as the forward and backward pointers to the free list of link table 
entries, and whether or not more pages can be allocated to the link 
table . 

A process can have up to 65,535 links, but in most cases can operate 
with far fewer. Thus, pages of memory are allocated to the link table 
as the links are used up. This is to avoid using large amounts of 
memory on "empty" link table space filled with free link table entries 
that would never be used. The task of managing link table space is 
done by the Link Manager. 
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At process creation time, each process is given, at the very minimum, a 
standard set of links. The pages needed to hold these links are 
allocated and frozen into memory. Any additional pages that are needed 
later can be allocated as required. However, regardless of the number 
of links initially given to the process, the page containing the link 
table header is always allocated'. Only the firmware can directly 
access allocated Link Table pages. 

The data structure describing a link contains the following 
information: 



Link Table Entry 



linkState 

Defined or undefined. A defined link is a link that has been 
successfully created. Messages are only allowed to be sent over a 
defined link. 

The following fields have meaning if, and only if, the link State is 
defined. 

toFunnel 

The identification number of the funnel into which the link is 
directed. A link may be directed into exactly one funnel. 

linkRights 

These are specified by the creator of the link at the time of 
creation. There are three types of rights associated with each 
link, specified by the creator of the link at the time of link 
creation: 

notificationRights 

These rights require the holder of the link to issue a 
notification message to the owner of the link when the link is 
copied, passed, or deleted. These notification rights are as 
follows: 

informOnPass 

Send notification to the link owner when the link holder 
has passed the link to another process. Passing a link 
differs from copying a link in that the process passing a 
link has that link deleted from its link table at the end 
of the operation. A process that passes a link no longer 
holds that link, whereas a process that copies a link will 
continue to hold that link at the completion of the 
operation. 
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informOnCopy. 

Send notification to the link owner when 
has copied the link to another process. 

informOnDelete 

Send notification to the link owner when 
has deleted the link from its link table. 



the link holder 



the link holder 



copy LinkRight s 

These confer upon the holder of the link the right to copy the 
link and/or the right to pass the link, as follows: 

canPass 

The link holder is allowed to pass the link to another 
process. 



canCopy The link holder is allowed to copy the link to 
process. 



another 



msgRights 

These confer upon the holder of the link the right of the 
holder to forward messages on the link and/or the right to send 
messages to the hardware (firmware) on the link. There rights 
are in addition to the right to send messages. For example, it 
is quite legal to send a regular message over a link with the 
toHardware right and it will be delivered to the software 
process specified in the link. However, it is not legal to 
send a message to the hardware over a link that does not have 
the To Hardware right. These are as follows: 

forwardMessage 

Messages may be forwarded over this link. 



toHardware 

Messages to the hardware (firmware) may be sent 
link. 



over this 



toProcess 

This is the process identification number of the process into whose 
funnel the link is directed. 

versionlD 

This is the version number associated with the process 
identification number in the toProcess field. The version ID 
prevents links with stale information in them from being used to 
send messages to new processes with recycled process ID'S. For 
example, process A sends a message to process B and process B's 
process ID is the same as the toProcess ID in process A's link to 
process B. If B's version ID is different from the version ID in 
A's link to B, then process B is not the same process as the one 
that existed when A's link to B was created, and A is so informed. 
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linkCode 

This is a 16-bit unsigned number, which the creator of the link may 
associate with the link. It has meaning only to the creator and 
holder of the link. The link code is available to the receiver of 
a message in the receive control information section of the 
parameter block. 

linkGrail 

This is a 48-bit array of booleans associated with the link. 

The following table indicates the bits corresponding to each link entry 
in the link table. These link entries may be read by the READ.LTE 
instruction. 
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Table 13-1. Link Table Entry 



! 000 <— 

! 001 <- 

/ !- 

/ 007 <- 

i 008 <- 
/ 009 



Link State 
unused 

— To Funnel 



/ 014 , 

015 <- 

016 <- 
017 
018 
019 
020 
021 
022 

023 <- 

024 <- 
025 

/ 



— Link Rights 



— To Process 



038 

039 <- 

040 <— 

041 < — 

042 <- 
043 



unused 
unused 



/ 

/ 

! 062 
| 063 <- 
| 064 <- 
J 065 ' 
/ 

/ 

| 078 
i 079 <- 
! 080 <- 
| 081 
/ 

/ 



— Version ID 



— Link Code 



— Link Grail 



126 
127 <- 



[0..1] undefined, defined 



Funnel ID 
type Integer 



unused 

Inform On Pass 
Inform On Copy 
Inform On Delete 
Can Pass 
Can Copy 
Forward Message 
To Hardware 



Process ID 
type Integer 
uses 16 bits 



Version ID of process 
type Integer 
uses 22 bits 



Link Code 
type Integer 
uses 16 bits 



Link Grail 
type Boolean 
uses 48 bits 
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13.3.2.2 Link Table Header 

The link table header resides in the first doubleword of the link table 
and contains the following information: 

linkHeaderState 

This is bit and is always set to zero. The Link Table Header is 
always tagged as being undefined so it will never be mistaken for a 
valid defined link table entry. 

maxCreatedLinkID 

This specifies the highest number link ID that has been created so 
far. Uses bits 16 to 31. 

fwdFreeLink 

This is the index to the next free link in the free link list. 
Uses bits 32 to 47 of the first word. 

revFreeLink 

This is the index to the previous free link in the free link list. 
Uses bits 48 to 63 of the first word. 

al locatablePage s 

This is a boolean bit, bit of the second word, and specifies 
whether or not additional pages can be allocated to the link table. 

allocatablePageCount 

This specifies the number of remaining pages that can be allocated 
to the link table for this process. Uses bits 8 to 23 of the 
second word. 



13.3.3 Funnels 

Each process in the system may have up to 255 funnels, although this 
number may be restricted by the creator of the process. Each funnel 
within the process has a unique identification number associated with 
it called the funnel ID. This number is used as an index into the 
table that contains the funnel table entries for this process. A valid 
funnel may have any number of links directed into it. 



13.3.3.1 Funnel Table Entries ' 

All the funnels within a process are organized into double-word entries 
in that process's funnel table. Each funnel table entry, as these are 
called, is either defined or free. A defined funnel table entry is one 
that has been created by the process and, as such, has its defined bit 
set and is attached to a channel. A free funnel funnel table entry is 
one that is available for creation and, as such, has its defined bit 
reset and is attached to the list of free funnels. This list consists 
of a doubly-linked group of free funnel table entries. Like the list 
of free links, the pointers to the head and tail of this list reside in 
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the header entry or funnel 0. An entry is removed from the free list 
when a funnel is created (by means of the CREATE . FUNNEL instruction), 
and a entry is added to the free list when a funnel is deleted (by 
means of the DELETE. FUNNEL instruction) . 

Each funnel table entry is indexed by an identifier called the funnel 
ID. Funnel ID'S span the range to 255. The full complement of 
funnels for a process can fit on two memory pages. Funnels with ID'S 
to 127 reside on the first page, and those with ID'S 128 to 255 reside 
on the second page. Since most processes will never use even 127 
funnels, they will be created with the second page of the funnel table 
unallocated. The first page will always be allocated, and the funnel 
table header entry will always be set up. 

The data structure defining a funnel contains the following 
information: 



Funnel Table Entry 

funnelState 

Defined or undefined. A defined funnel is one that has been 
successfully created. A link may be configured into a defined 
funnel. Deleting a defined funnel causes it to become undefined. 

The following fields have meaning if and only if the funnel State is 
defined. 

channellD 

The identification number of the channel to which the funnel is 
attached. All defined funnels must be attached to exactly one 
channel. When a funnel is created it is attached to channel number 
15. The user may move the funnel to any channel (except channel 0) 
with the Attach Funnel To Channel instruction. 

nextFunnel 

This field only has meaning if there are messages queued on this 
funnel. Then it contains the funnel ID of the next funnel that 
also has messages queued up and is attached to the same channel. 
This singly linked pointer string forms what is called the active 
funnels list for that channel. Only active funnels (those with 
queued messages) are linked into this list. The funnel at the tail 
of this list will have zero value in its nextFunnel field. 

messageCount 

The number of messages currently delivered to the funnel but not 
yet received. The count is a 16-bit integer. 



13 - 22 



INTER-PROCESS COMMUNICATIONS 



interruptVector 

The virtual address of the interrupt handler invoked when an 
interrupt is generated for this funnel. If interrupts are never 
generated for messages delivered into this funnel, then the 
interrupt vector may be zero. Note, however, that if an interrupt 
was ever to be generated with an address of zero, an access 
violation would occur. 

headBuffer 

Messages delivered into a funnel, but not yet received, are 
organized into a singly linked list of system message buffers. 
HeadBuffer holds the physical address of the first message buffer 
in this list. When a receive is executed, headBuffer is used to 
dequeue the first message on this funnel. 

tailBuffer 

This field holds the physical address of the last system message 
buffer in the funnel's queue of unreceived messages. When a 
message is being delivered, tailBuffer is used to append the new 
message onto the tail of this list. The operations that enqueue 
and dequeue messages from the funnel queue exist to maintain the 
list in FIFO order. If no messages have been delivered into the 
funnel, then the head and tail buffer addresses are zero. 
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Table 13-2. Funnel Table Entry 



000 


<" 


Funnel state 


001 


<- 




002 




— unused 


003 


<- 




004 


<- 




005 




— Channel ID 


006 






007 


<- 




008 


<- 




009 






010 






Oil 




— Next Funnel 


012 






013 






014 






015 


<- 




016 


<- 




017 







/ 

/ 



030 

031 <- 

032 <- 
033 



— Message Count 



/ 

/ 



062 

063 <- 

064 <- 
065 



— Interrupt Vector 



/ 
/ 



094 

095 <- 

096 <- 
097 



— Head Buffer 



/ 



— Tail Buffer 



126 
127 <- 



[0..1] undefined, defined 



Channel ID 
type Integer 



Funnel ID 
type Integer 



Number of messages 
type Integer 
uses 16 bits 



Interrupt vector 
32-bit virtual address 
uses 32 bits 



Start address of msg buffer 
32-bit physical address 
uses 32 bits 



End address of msg buffer 
32-bit physical address 
uses 32 bits 
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13.3.3.2 Funnel Table Header 

The funnel table header resides in the first doubleword of the funnel 
table and contains the following: 

funnelHeaderState 

This is bit of the first word and is always set to zero. The 
funnel table header entry is always tagged as undefined so that it 
will never be mistaken for a valid funnel table entry. 

maxCreatedFunnellD 

This contains the highest numbered funnel ID created so far. This 
uses bits 16 to 23. 

fwdFreeFunnel 

This is the ID (index) of the next free funnel in the list of free 
funnels. It uses bits 48 to 55. 

re vFreeFunne 1 

This is the ID (index) of the previous free funnel the list of free 
funnels. This uses bits 56 to 63 of the first word. 

allocatablePages 

This is bit of the second word and specifies whether or not a 
second page can be allocated to the funnel table. 



13.3.4 Channels 

Channels allow users to organize funnels and prioritize the receiving 
of messages. Every process has 16 channels (channel through channel 
15) , and every channel has a message system priority associated with 
it. The associated priority is the same as the channel number, with 
priority being the highest and priority 15 the lowest. This priority 
is called the local priority because its scope is local to that process 
only. It has direct bearing on what that process will do next and 
which queued message will be received next. A channel may have from 
to 255 funnels attached to it. All of the funnels attached to a 
particular channel will have that channel's priority. 

Channels may be interrupting or non-interrupting. Interrupting 
channels are those that have been enabled for interrupts; non- 
interrupting channels are those that have been disabled for interrupts. 

A channel mask is used to designate which of the 16 channels are 
interrupting and which are non-interrupting. Bit of this mask is 
associated with channel 0, bit 1 with channel 1,..., bit 15 with 
channel 15. Each bit set on indicates that the corresponding channel 
is enabled for interrupts; each bit set off means that the 
corresponding channel has interrupts disabled. The user can modify the 
channel mask by issuing the EN ABLE. CHANNEL. INT and DISABLE. CHANNEL. INT 
instructions . 
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There are, however, architectural restrictions placed on the interrupt 
structure : 

1. The priority of interrupting channels must be higher than the 
priority of non-interrupting channels. 

2. The above implies that interrupting channels and non- 
interrupting channels must exist in two separate groups, since 
an interrupting channel followed by a non-interrupting channel 
can never be followed by another interrupting channel. 

To reiterate, the basic premise of the interrupt structure is this: 
The arrival of a message on a funnel that is attached to an 
interrupting channel will cause an interrupt to occur. 

Channel is used in special ways by the operating system. As such, it 
has some special restrictions associated with it: 

1. Channel is always interrupting and can never be disabled. 

2. No funnel may be attached to channel with the 
ATTACH. FUNNEL. TO. CHANNEL instruction. The only funnel attached 
to this channel is the lifeLine funnel (f unnellD = 1) , and this 
funnel can neither be disabled nor moved to another channel. 



13.4 PRIORITY STRUCTURE OF MESSAGE SYSTEM 

The priority structure is an ordering . scheme through which execution 
priority is defined. There are two kinds of priority: Local Priority 
and Global Priority. Local Priority applies locally to a process and 
is used to determine which message that process will receive next or 
what task that process will perform next. Global Priority applies to 
all living processes on a particular CPU. It crosses process bound- 
aries and is used by the Scheduler to determine the execution order of 
the processes that are ready to run. 

Local Priority and Global Priority are related to each other and are 
mapped into one another in the channel priority map. This maps a local 
priority which can range in value from to 15 into a global priority 
which can range in value from to 255. In general, Local Priority 
values and Global Priority values track each other in the sense that a 
high local priority will be mapped into a correspondingly high global 
priority. There are, however, no architectural constraints that 
local/global priorities follow such a pattern. 
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13.4.1 Local Priority 

Local Priority Local priority has -meaning only within an individual 
process. Its value can be explicitly modified by the user with the 
SET. LOCAL. PRIORITY instruction or implicitly modified by the firmware 
(which performs the set local priority function when delivering 
messages or exiting from an interrupt with the IXIT instruction) . The 
way the set local priority function works is to modify the local 
priority of the process to either the specified value or the channel 
number of the highest priority active channel, whichever is higher in 
priority. A channel is active when any funnel attached to that channel 
contains a message. As such, the local priority will often be at the 
priority of the highest priority active channel. For example, if 
funnel 200 with a queued message is attached to channel 10, funnel 14 
with a queued message is attached to channel 5, and only these two 
channels contain messages, then the resulting local priority would be 
5. Should a message be delivered into a funnel attached to a higher 
priority channel, then the local priority of the process would be 
raised. On the other hand, the delivery of a message into a funnel 
attached to a lower priority channel will not change the local 
priority. 

Message delivery can only raise the local priority of a process. A 
process generally has its local priority raised to a high level so it 
can vie for additional system resources (at the expense of other 
processes) in order to get certain demanding tasks done in a timely 
manner. (Note that a high local priority value normally translates 
into a high global priority value, and a high global priority means a 
high scheduling priority) . If the process were left at this high 
priority, it would continue to usurp system resources that it really 
did not need. Consequently, once the process has completed its high 
priority tasks, its local priority must be lowered. The can be done in 
several ways: 

o It can issue the SET. LOCAL. PRIORITY instruction and specify that 
the local priority be set to the "base" local priority value for 
this process. 

o The RECEIVE instruction that was used to receive the high 
priority message can specify the DISMISS option which on the 
completion of the receive operation will perform a a set local 
priority with a priority value of 15. This will lower the 
process priority to that of the highest priority active channel, 
or, if no channels are active, to a local priority of 15. 

o If the high local priority has come about because of servicing 
an interrupt, the lowering of priority will occur automatically 
when the process returns from the interrupt handler through the 
IXIT instruction. The last part of this instruction performs a 
set local priority with the priority value set to the local 
priority that the process had prior to the delivery of the 
interrupting message (Chapter 2 describes how the old local 
priority is placed onto the stack on the occurrence of an 
interrupt) . The process local priority upon return from the 
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interrupt handler will be the higher of either the restored old 
local priority or the value of the highest priority active 
channel . 



13.4.2 Global Priority 

Global priority is the execution priority of a particular process 
relative to all other processes in the system. It is used by the 
operating system to control resource allocation and may be dynamically 
modified to effect load balancing among all the processes executing in 
the system. A global priority is assigned to each of the 16 local 
priorities, and to each of the 16 channels since channel numbers and 
local priority values have a one-to-one correspondence. The mapping of 
these assignments is held in the channel priority map of that process's 
PCB (Process Control Block) . The global priorities for each process 
are assigned to each channel at process creation time. These 
assignments are not modifiable by the user, but they may be modified by 
the operating system from time to time. 

When a process becomes eligible for execution, it is put into a queue 
of eligible processes called the Active List. The processes in this 
list are ordered according to global priority, and those with high 
global priorities are given preferential treatment by the scheduling 
mechanism. As a result, high priority processes are allowed to execute 
sooner and more often than low priority processes. This priority 
scheme together with the setting of time quantums restricting how long 
each process can run at a single stretch form the basic components of 
the scheduling mechanism. 



13.5 STANDARD COMMUNICATION PATHS 

When a process is started, it has a set of standard links and funnels 
already created by EMBOS. These links and funnels have ID'S in the 
range 1-20. This range of link and funnel IDs is reserved for EMBOS, 
so the user should not delete any predefined link or funnel, or create 
a link or funnel with a preferredLink (Funnel) ID in the range 1-20. 
Since all links and funnels in the range 1-20 are not presently used, a 
createLink (createFunnel) with a preferredLink (Funnel) ID of may 
result in the creation of a link or funnel in the range 1-20. This 
will cause no problems, since all EMBOS-reserved links and funnels are 
created before the user's code begins executing. 
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13.5.1 Standard Links 

The standard links for each process consist of special self -links and 
communcation paths to the process' parent and to certain system 
processes. The only LinkID relevant to this document is the following: 

userExceptionLinkID (linkID = 1) 

This link is directed into the process* userExceptionFunnel 
(funnellD = 2) and is used by firmware and software to send user 
interceptable exception messages to the process. 



13.5.2 Standard Funnels 

The standard funnels for each process consist of funnels into which 
self-links, and links from the process' parent, and certain system 
processes are directed. The two funnels relevant to this document are: 

userLifelineFunnel (funnellD = 1) 

This funnel is attached to channel 0. The firmware prevents this 
funnel from being altered in any way. It cannot be deleted, 
disabled, attached to a different channel, have its interrupt 
vector changed, or have links created into it. Any receive on the 
funnel will always find it empty, so a synchronous receive will 
wait forever (or until an interrupt occurs) . 

userExceptionFunnel (funnellD = 2) 

This is the funnel into which the userExceptionLink belonging to 
the process is directed. The funnel is attached to channel ID 1, 
and has an interrupt vector which points to an EMBOS supplied 
exception dispatcher. All user interceptible exceptions arrive on 
this funnel. The exception dispatcher receives all exception 
messages and invokes the appropriate exception handler. 
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14 MESSAGE SYSTEM INSTRUCTIONS 

The message system instructions are used for implementing and modifying 
communication structures. These instructions should not be considered 
as the primary user interface to the message system, as software for 
this purpose is included in all ELXSI supplied languages. 



ATT. FUN. TO. CHAN 

COPY. LINK 

CREATE. FUN 

CREATE. LINK 

DEL. FUN 

DEL. LINK 

DEL.MSG 

DISABLE. CHAN. INT 

DISABLE. FUN 

ENABLE. CHAN. INT 

ENABLE. FUN 

EXCH . LINK. FORWARD 

FORWARD. MSG 

PASS. LINK 

RCV 

RCV.CHAN 

RCV. LINK 

RCV. LINK. ON. CHAN 

READ.FTE 

READ.LTE 

SEND 

SEND. SMALL. MSG 

SEND . TO . HARDWARE 

SET . FUN . INT . VECTOR 

SET. LOCAL. PRI 



Attach Funnel to Channel 

Copy Link 

Create Funnel 

Create Link to Funnel 

Delete Funnel 

Delete Link 

Delete Message from Funnel 

Disable Interrupts on Channel 

Disable Funnel 

Enable Interrupts on Channel 

Enable Funnel 

Exchange Message Link and Forward 

Forward Message 

Pass Link 

Receive Message 

Receive Message on Channel 

Receive Message with Link 

Receive Message with Link on Channel 

Read Funnel Table Entry 

Read Link Table Entry 

Send Message 

Send Small Message 

Send Message to Hardware 

Set Funnel Interrupt Vector 

Set Local Priority 



The message system instructions return a status code to the calling 
process. These codes tell the user whether the operation Was 
successful or not, and can also provide information on abnormal 
conditions encountered during execution of the instruction. The status 
code is instruction specific and is returned in register Rx as a right 
justified integer value. 

A list of the status codes is provided with each instruction. The 
column to the right of these codes provide information on whether or 
not the instruction executed successfully. A "y" indicates that the 
associated status is merely an advisory. An "n" indicates that the 
instruction has partially or completely failed. 
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A summary of the codes is provided below: 



Table 14-1. 



Status Return Codes 



1 = MSYS Funnel Does Not Exist 

2 = MSYS Illegal Channel ID 

3 = MSYS Funnel Not Disabled 

4 = MSYS Funnel Not Empty 

5 = MSYS Transport Hardware Error On Notification 

6 = MSYS Message Too Long 

7 = MSYS Illegal to Modify Interrupt Vector On This Funnel 

8 = MSYS Funnel Table Is Full 

9 = MSYS Illegal Preferred Funnel ID 

10 = MSYS Funnel Already Created 

11 = MSYS Link Table Is Full 

12 = MSYS Link Already Created 

14 = MSYS No Message In Funnel 

15 = MSYS Illegal To Disable Interrupts 

17 = MSYS Illegal To Disable Funnel ID 

18 = MSYS Specified Funnel Already Disabled 
21 = MSYS Specified Funnel Already Enabled 
23 = MSYS Cannot Forward On Link 

28 = MSYS Message Contains Link 

29 = MSYS No Messages On Channels 

30 = MSYS Message Does Not Contain Link 

31 = MSYS Link Does Not Have Hdwr Right 

32 = MSYS Illegal Preferred Link ID 
34 = MSYS Illegal To Move Funnel 

36 = MSYS Link 1 Receiving Process Dead 

37 = MSYS No Message Buffer Available 

38 = MSYS Too Many Buffers In Transit 

39 = MSYS Link 1 Too Many Attached Buffers 

40 = MSYS Link 1 Link Not Defined 

41 = MSYS Link 1 Unallocated Page 

42 = MSYS Link 1 Unallocatable Page 

43 = MSYS Link 1 Exceeds No Of Link Levels 

45 = MSYS Link 1 Zero Link ID 

46 = MSYS Negative Data Block Length 

47 = MSYS Link 1 Funnel Not Enabled 

48 = MSYS Destination Process Not On Target Unit 

49 = MSYS Bad Pointer In Free Link 

50 = MSYS Access Unallocated Page Of Funnel Table 

51 = MSYS Link Cannot Be Sent 

52 = MSYS Link 1 Target Unit Busy 
54 = MSYS Message Not Sent 

54 = MSYS Transport Hardware Error On Data Message 

55 = MSYS Transport Hardware Error 

56 = MSYS Link Fault 

136 = MSYS Link 2 Receiving Process Dead 

139 = MSYS Link 2 Too Many Attached Buffers 

140 = MSYS Link 2 Link Not Defined 

141 = MSYS Link 2 Unallocated Page 

142 = MSYS Link 2 Unallocatable Page 
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143 = MSYS Link 2 Exceeds No Of Link Levels 

145 = MSYS Link 2 Zero Link ID 

147 = MSYS Link 2 Funnel Not Enabled 

152 = MSYS Link 2 Target Unit Busy 



Descriptions of the data structures, such as the Funnel Table Entry 
(FTE) and the Link Table Entry (LTE) , may be found in Chapter 13, 
"Inter-Process Communications". The message length, when specified, is 
in bytes. All unused fields must be set to zero. 

Channel masks are 16-bit right justified fields that are used to select 
or deselect channels for particular instructions. Each bit corresponds 
to a channel. If the bit is set to '1', the indicated function is 
performed for that channel. Bits set to '0' have no effect. 



CHANNEL MASK in Ry, right justified 

Channel -> 00 01 02 ... • ... 12 13 14 15 
< / / 

i o [ i ! i ; o o ; i | o | i ! i | 

< / / 

Bit position 47 48 49 . . . ... 60 61 62 63 



The channels selected above are channels [0,1,12,14,15]. Observe that 
the logical relation of this mask to the object is defined by the 
instruction, whereas a returned operand will be the actual object. For 
example, assume that the enabled channels in the channel mask happen to 
be = 1010101010101010 and we perform a DISABLE. CHAN. INT with the above 
mask. The new word will be 1000101010100000 and the returned (old) 
word will be 1010101010101010. 



14.1 CREATE A COMMUNICATION PATH 

To send a message to another process, a link must be established that 
is directed into the funnel of the receiving process. One may then 
send messages via the link. 

If a process (A) is already sending to process (B) but wishes to 

receive messages from process (B) , process (A) must create a link 

directed into one of its own funnels, and then copy or pass the link to 

process (B) . The link attributes are discussed in Chapter 13, 
"Inter-Process Communications". 
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14.1.1 CREATE. LINK Create Link to Funnel 

All links are created with tnis instruction and are self links, that 
is, they are directed into one of the creator's own funnels. The link 
configuration is specified in the create link parameter block whose 
address is in Ry. The instruction places the configuration into the 
link table belonging to the process. Upon completion, status is 
returned in Rx. 



Implementation 



Addressing mode usage 
CREATE. LINK Rx, [Ry] 



8|0i2!x[y!0; 



Opcode 



This field must be zero 



Ry parameter block address 



Rx = Instruction Specific Return Status 



= Success [y] 

1 = Funnel Does Not Exist [n] 

11 = Link Table Is Full [n] 

12 = Link Already Created [n] 
32 = Illegal Preferred Link ID [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



If the link ID specified in the parameter block is zero, then the next 
free link is created, otherwise the specified link is created. The 
link ID actually created is returned in the parameter block in the link 
ID field. If [Rx] <> 0, then the link is not created. Following are 
descriptions of the parameter block fields. 

Link ID 

This is the link ID of the link to be created or zero, if the next 
undefined link ID is to be used. The firmware returns the link ID 
actually created in this field upon successful completion. 

Funnel ID 

This is the funnel ID in the creator's Funnel Table into which the 
link being created will be directed. The funnel must have been 
created prior to creating the link. 
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Link Rights 

These are boolean rights associated with the link, presented from 
high order to low order in the field. The To Hardware Right may 
never be specified for this instruction. These rights are as 
follows: 

Unused 

Inform on Pass (notify link creator when passing link) 

Inform on Copy (notify link creator when copying link) 

Inform on Delete (notify link creator when deleting link) 

Can Pass Link (link can be passed to another process) 

Can Copy Link (link can be copied to another process) 

Can Forward Message (messages may be forwarded on this link) 

To Hardware (messages to hardware may be sent on this link) 

Link Code 

This is a 16-bit unsigned integer which may contain information 
specified by the link creator. The default value is 0. 

Link Grail 

This is an array of 48 booleans. The default is 48 bits of zero. 

A full description of these data structures may be found in Chapter 13, 
"Inter-Process Communications". 



CREATE. LINK Parameter Block 



[Ry]-> 



Funnel ID (8) J Link Rts (8) J 


Link ID (16) 




<unused> (32) 


Link Code (16) | 


Link Grail (16) 


-> 


— > Link Grail (32) 



14.1.2 CREATE. FUN Create Funnel 

Before a link can be created into a funnel or a message received on a 
funnel, the funnel must be created. Funnels are always created 
attached to channel 15. 

The funnel specified in Ry is created as follows: if [Ry] = 0, the 
next funnel on the list of free funnels is used, otherwise the 
specified funnel is used. The funnel table entry corresponding to the 
specified funnel ID is removed from the list of free funnels. Its 
defined bit is set, it is attached to channel 15, and the rest of its 
fields are set to initial values. The funnel channel map entry for 
this funnel is updated to show this funnel attached to channel 15. 
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Upon completion, the actual ID of the funnel created is returned in Ry, 
and the status is returned in Rx. If [Rx] <> 0, then no funnel is 
created. 



Implementation 



Addressing mode usage 
CREATE. FUN Rx,Ry 



! 8 ! ! 1 



x | y | | 



Opcode 



This field must be zero 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success [y] 

8 = Funnel Table Is Full [n] 

9 = Illegal Preferred Funnel ID [n] 
10 = Funnel Already Created [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



14.1.3 ATT. FUN. TO. CHAN Attach Funnel to Channel 

All funnels are attached to channel 15 when created, 
allows the user to move a funnel to another channel. 



This instruction 



The instruction attaches the funnel specified in Ry to the channel 
specified in Rz. Upon completion, status is returned in Rx and the 
channel to which the funnel was previously attached is returned in Rz. 
If [Rx] <> 0, then Rz is unchanged. A funnel cannot be attached to 
channel 0. 
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Implementation 



Addressing mode usage 



| 8 | I | x I y 



Opcode 



ATT. FUN. TO. CHAN 



Rx,Ry,Rz 



Rz Channel ID 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success [y] 

1 = Funnel Does Not Exist [n] 

2 = Illegal Channel ID [n] 
34 = Illegal To Move Funnel [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



This instruction modifies the funnel table entry and the funnel channel 
map for the funnel specified in Ry. The addresses of both data 
structures are known to the system. 



The funnel specified in Ry must have been created with 
instruction prior to executing this instruction. 



the CREATE. FUN 



14.2 DESTROY A COMMUNICATION PATH 

These instructions delete the links and funnels belonging to a process. 
Deleting standard links and funnels may produce unexpected results. 



14.2.1 DEL. LINK Delete Link 

The specified link is deleted from the link table and returned to the 
list of free links. The first word in the parameter block contains the 
link ID to be deleted. If "Inform on Delete" is specified in the link 
entry for the link to be deleted, a notification message is sent to the 
creator of the link. Ry contains the address of the parameter block. 
The notification message will not be sent if the link creator deletes a 
link that is directed into one of its own funnels. 
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Implementation 



Addressing mode usage 



9 J 



: i ! x ; y : o ; 



DEL. LINK 



Rx,[Ry] 



Opcode 



This field must be zero 



Ry parameter block address 



Rx = Instruction Specific Return Status 



Receiving Process Dead 
Link Not Defined 
Unallocated Page 
Unallocatable Page 
Exceeds No Of Link Levels 
Zero Link ID 
Funnel Not Enabled 
Transport Hardware Error 
Too Many Attached Buffers 






= 


Succes 


36 


= 


Link 1 


40 


= 


Link 1 


41 


= 


Link 1 


42 


= 


Link 1 


43 


= 


Link 1 


45 


= 


Link 1 


47 


= 


Link 1 


55 


= 


Link 1 


139 


= 


Link 1 



[y] 
[y] 

[n] 
[n] 
[n] 
[n] 
[n] 

[y] 
[y] 
[y] 



DEL. LINK Parameter Block 



[Ry]->; 



<unused> (16) 



Link ID (16) 



<unused> (32) 



Notification Message to Link Creator 



Link Code (16) 
From Process ID (16) 



Funnel ID (8) | Msg type (8) 



Number of Bytes (16) 
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14.2.2 DEL. FUN Delete Funnel 

The funnel specified in Ry is deleted by returning its entry in the 
funnel table to the free list. Prior to deleting a funnel, it must be 
disabled by executing the DISABLE. FUN instruction, and all messages 
must be removed from its funnel queue by executing the DELETE. MESS AGE 
instruction. Upon completion, status is returned in Rx. 



Implementation 



Addressing mode usage 
DEL. FUN Rx,Ry 



! 8 ! ! 3 



x J y | i 



Opcode 



This field must be zero 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success ty] 

1 = Funnel Does Not Exist [n] 

3 = Funnel Not Disabled [n] 

4 = Funnel Not Empty [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



14.3 SEND MESSAGES 



There are three types of messages a user may send, 
below by the instructions used in sending them. 



They are listed 



o SEND. This is used to send the typical message. The length of 
this message may vary from bytes to a maximum of 888 bytes. 
The message data to be sent can be organized into one or two 
(not necessarily contiguous) data blocks in the user's virtual 
space. The message preamble and the message data are 
transferred into message buffers (see Chapter 13, "Inter-Process 
Communications") contributed by the sending functional unit. 

o SEND. SMALL. This type allows the user to place a 32-bit message 
into a register and send it to another process. The receiving 
functional unit, rather than the sending functional unit, 
contributes the message buffer for this kind of send. 

o SEND. TO. HARDWARE. This sends a message to the hardware (CPU) 
being used by the process into which the link is directed. A 
link can only have the toHardware link right conferred to it via 
system intrinsics not covered in this section. No message 
buffer is required to send this 64-bit message to the hardware. 
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The maximum size of a message is 888 bytes. If a link is contained in 
the message, as with COPY. LINK or PASS. LINK, the link uses 16 bytes, 
leaving a remainder of 872 bytes for message data. 



14.3.1 SEND Send Message 

This instruction copies the specified message from the caller's virtual 
address space to the system message buffers, then attaches the buffer 
to the funnel specified in the link table entry for the sending 
process. Ry contains the virtual address of the send parameter block 
and Rz the length of the message data. If [Rv] <> o, then the message 
is in two parts, with Rt containing the virtual address of the second 
message block and Rv the length. Upon completion, status is returned 
in Rx. 



i Implementation 
! 9 ! J A 



Addressing mode usage 
SEND Rx,[Ry] ,Rz,[Rt],Rv 



; x ; y | z ; t ; v ; 



Opcode 



_Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 

= Success 

6 = Message Too Long 

36 = Link 1 Receiving Process Dead 

39 = Link 1 Too Many Attached Buffers 

40 = Link 1 Link Not Defined 

41 = Link 1 Unallocated Page 

42 = Link 1 Unallocatable Page 

43 = Link 1 Exceeds No Of Link Levels 

45 = Link 1 Zero Link ID 

46 = Negative Data Block Length 

47 = Link 1 Funnel Not Enabled 
55 = Transport Hardware Error 



[y] 

Cn] 
tn] 
[n] 
[n] 
[n] 
[n] 
tn] 
tn] 
tn] 
[n] 
tn] 
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SEND Parameter Block 



[Ry3->! 



<unused> (16) 



Link ID (16) 



<unused> (32) 



Rz 



Message data block 1 



[Rt]-> 



Rv 



Message data block 2 



14 - 11 



MESSAGE SYSTEM INSTRUCTIONS 



14.3.2 SEND. SMALL. MSG Send Small Message 

The data in the low order 32 bits of Rz (bits 32 through 63) are formed 
into a message, and sent on the link specified in Ry. High order bits 
through 31 of Rz must be zero. Upon completion, status is returned 
in Rx. 



Implementation 



Addressing mode usage 



\ e \ o \ e \ * \ y \ z \ 



SEND. SMALL. MSG 



Rx,Ry,Rz 



Opcode 



Rz Message data 



Ry Link ID 






_ 


Success 


[y] 


36 


= 


Link 1 Receiving Process Dead 


[n] 


37 


= 


No Message Buffer Available 


[n] 


40 


= 


Link 1 Link Not Defined 


[n] 


41 


= 


Link 1 Unallocated Page 


[n] 


42 


= 


Link 1 Unallocatable Page 


[n] 


43 


= 


Link 1 Exceeds No Of Link Levels 


tn] 


45 


= 


Link 1 Zero Link ID • 


[n] 


47 


= 


Link 1 Funnel Not Enabled 


[n] 


55 


— 


Transport Hardware Error 


[n] 



14.3.3 SEND. TO. HARDWARE Send Message to Hardware 

This instruction is similar to the SEND . SMALL . MSG instruction, except 
that the message is not received by the specified target. Instead, the 
message is interpreted by the CPU that owns the target process. The 
64-bit data in Rz is formed into a message, and is sent on the link ID 
specified in Ry. Upon completion, status is returned in Rx. 
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The link on which this message is 
specified by the link creator. 



sent must have toHardware rights 



Implementation 



Addressing mode usage 



; e : 



I D 



y ! z ! 



SEND. TO. HARDWARE Rx,Ry,Rz 



Opcode 



Rz Message data 



Ry Link ID 



Rx = Instruction Specific Return Status 

= Success 

31 = Link Does Not Have Hardware Right 

36 = Link 1 Receiving Process Dead 

40 = Link 1 Link Not Defined 

41 = Link 1 Unallocated Page 

42 = Link 1 Unallocatable Page 

43 = Link 1 Exceeds No Of Link Levels 
45 = Link 1 Zero Link ID 

55 = Transport Hardware Error 



[y] 
[n] 
[n] 
[n] 
[n] 
[n] 
tn] 
[n] 
tn] 



14.3.4 COPY. LINK Copy Link 

This instruction copies a link along with a message from the caller's 
virtual address space to the system message buffers, then attaches the 
buffer to the funnel specified in the caller's link table. This 
instruction is identical to SEND with the addition of a link ID to copy 
as specified in the parameter block. A link must be defined in order 
to be copied. 

The receiver of a link places the link into its link table. The link 
attributes of the original and the copied link both have the same 
funnel, that is, an additional link is now directed into the funnel. 

Ry contains the address of the first send parameter block and Rz 
contains the length of the data (message) in the parameter block. Rt 
contains the address of the second message block and Rv contains the 
length of the data in the second message block. If [Rv] = 0, there is 
no second message block and the contents of Rt have no meaning. Upon 
completion, the status is returned in Rx. 
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A notification message is sent to the creator of the link only if 
"notify on copy" is specified in the link entry for the copied link. A 
notification message is never sent, regardless of the setting of the 
"notify on copy" bit, if the owner (creator) of the link is the process 
invoking COPY. LINK. 



Implementation 



Addressing mode usage 



9 ; o ; o ; x | y ; 



t : v : 



COPY. LINK Rx,[Ry],Rz,[Rt],Rv J 



Opcode 



Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 



= Success [y] 

5 = Transport Hardware Error On Notification [n] 

6 = Message Too Long [n] 
36 = Link 1 Receiving Process Dead [n] 

39 = Link 1 Too Many Attached Buffers [n] 

40 = Link 1 Link Not Defined [n] 

41 = Link 1 Unallocated Page [n] 

42 = Link 1 Unallocatable Page [n] 

43 = Link 1 Exceeds No Of Link Levels [n] 

45 = Link 1 Zero Link ID [n] 

46 = Negative Data Block Length [n] 

47 = Link 1 Funnel Not Enabled [n] 

51 = Link Cannot Be Sent [n] 

52 = Link 1 Target Unit Busy [n] 
54 = Transport Hardware Error On Data Message [n] 

136 = Link 2 Receiving Process Dead [n] 

139 = Link 2 Too Many Attached Buffers [n] 

140 = Link 2 Link Not Defined [n] 

141 = Link 2 Unallocated' Page [n] 

142 = Link 2 Unallocatable Page [n] 

143 = Link 2 Exceeds No Of Link Levels [n] 
145 = Link 2 Zero Link ID [n] 
147 = Link 2 Funnel Not Enabled [n] 
152 = Link 2 Target Unit Busy [n] 
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COPY. LINK Parameter Block 



[Ry]->! 



<unused> (16) 
<unused> (16) 



; Link ID (16) 
I Link ID to Copy (16) 



Rz 



Message data block 1 



[Rt]-> 



Rv 



Message data block 2 



Notice that execution of the COPY. LINK instruction simply allows the 
receiving process to place the link in the message into its link table. 
The link owner now has two links directed into one of its funnels: the 
original link that the process created or held that was directed into 
its own funnel, and the copied link now held by the receiver of the 
message. 



14 - 15 



MESSAGE SYSTEM INSTRUCTIONS 



The notification message to the creator of the link, if sent, has the 
following format: 



COPY. LINK notification message 



Link Code (16) 



Funnel ID (8) j Msg type (8) 



From Process ID (16) 
Receive Process ID (16) 



Number of Bytes (16) 
<unused> (16) 



14.3.5 PASS. LINK Pass Link 

PASS. LINK is identical to COPY. LINK, except that after the link to be 
passed is put in the message, the entry for it is deleted from the 
holder's link table. When the receiver of the link does a receive 
link, there will still be only one link. Ry contains the address of 
the first send parameter block and Rz contains the length of the data 
(message) in the parameter block. Rt contains the address of the 
second send parameter block and Rv contains the length of the data 
(message) in the parameter block. If [Rv] = 0, then there is no second 
parameter block, and the contents of Rt have no meaning. Upon 
completion, status is returned in Rx. 

If the Link Rights field of the link to be passed specifies "inform on 
pass" , then a default notification message will be sent to the creator 
of the link. (See Section 14.3.4, "COPY. LINK", for diagrams and 
contents of notification message.) If the "inform on pass" bit is set, 
.and the owner of the link is invoking PASS. LINK, no notification 
message is sent. 
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Implementation 



Addressing mode usage 



' 9 ' 



0i5lx!y!z!t|v| 



PASS. LINK Rx,[Ry],Rz,[Rt],Rv 



Opcode 



Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 



= Success [y] 

5 = Transport Hardware Error On Notification [n] 

6 = Message Too Long [n] 
36 = Link 1 Receiving Process Dead [n] 

40 = Link 1 Link Not Defined [n] 

41 = Link 1 Unallocated Page [n] 

42 = Link 1 Unallocatable Page [n] 

43 = Link 1 Exceeds No Of Link Levels [n] 

45 = Link 1 Zero Link ID [n] 

46 = Negative Data Block Length [n] 

47 = Link 1 Funnel Not Enabled [n] 
49 = Link 1 Too Many Attached Buffers [n] 

51 = Link Cannot Be Sent [n] 

52 = Link 1 Target Unit Busy [n] 
54 = Transport Hardware Error On Data Message [n] 

136 = Link 2 Receiving Process Dead [n] 

139 = Link 2 Too Many Attached Buffers [n] 

140 = Link 2 Link Not Defined [n] 

141 = Link 2 Unallocated Page [n] 

142 = Link 2 Unallocatable Page [n] 

143 = Link 2 Exceeds No Of Link Levels [n] 
145 = Link 2 Zero Link ID [n] 
147 = Link 2 Funnel Not Enabled [n] 
152 = Link 2 Target Unit Busy [n] 
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14.4 RECEIVE MESSAGES 

The receive instructions provide several means of interfacing to the 
system message buffers. 

Observe that the microcode adds the length of the parameter block to 
the number of bytes specified in Rz to determine the address space for 
the parameter block and the first message block. The parameter block 
will always be stored at [Ry]. The message itself may be stored at [Ry 
+ 4 words] with Rz length, or stored at [Rt] with Rv length, or split 
up with the first part of the message at the former address, and the 
second part at the latter address. The "number of bytes" specified in 
the receive control part of the parameter block only includes the 
length of the message data areas, not the parameter block. The user 
would typically allocate 888 bytes + length of parameter block 
(16 bytes) to cover worst cases. 



14.4.1 RCV Receive Message 

Copies the first message on the specified funnel into the user's 
virtual address specified in Ry, for the number of bytes specified in 
Rz. Optionally, if [Rv] <> 0, then the message is copied into two 
buffers. If so, then Rt contains the virtual address of the beginning 
of the second buffer and Rv specifies the length of the buffer. Upon 
completion, status is returned in Rx. 
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Implementation 



Addressing mode usage 



; 9 | i 7 



! x ! y ; 



z | t 



: v i 



RCV 



Rx, [Ry] ,Rz, [Rt] ,Rv 



Opcode 



Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 

= Success 

1 = Funnel Does Not Exist 
6 = Message Too Long 

14 = No Message In Funnel 

28 = Message Contains Link 

55 = Transport Hardware Error 



[y] 

[n] 
[n] 
[n] 
[n] 
tn] 



RCV Parameter Block 



[Ry]->; 


Funnel ID (8) | <unused> (8) J 


Type rev (8) ] <unused> (8) 




<unused> (16) [ 


<unused> (16) 


RCV | 
CTL 
INFO ; 


Link Code (16) | 


Funnel ID (8) \ Msg type (8) 


From Process ID (16) \ 


Number of Bytes (16) 


i i 
i i 

Rz ! 


Message data 


block 1 
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[Rt ] -> 

i 

Rv j Message data block 2 

i i 
i i 



The parameter fields are defined as follows: 

Funnel ID 

This is the funnel from which to take the message if there is a 
message. 

Type of receive 

This specifies the kind of receive the user wishes to execute and 
contains the following boolean values: 

Synchronous 

If there is no message in the specified funnel, the user is 
blocked until a message is delivered into the funnel. 
(Bit-7 of field) . 

Interrogate 

The message, if any, is copied into the users virtual address 
space, but the message remains attached to the funnel. If 
there is no message, the action is controlled by the 
synchronous specification. (Bit-6 of field) . 

Dismiss 

This option implicitly sets the local priority to a value 
previously specified by the SET . LOCAL . PRI instruction, or to 15 
before any modification of local priority by the user. The 
specification will be invoked prior to the receive. 
(Bit-5 of field) . 

If the user executes a RCV and the system detects that the message 
contains a link, then RCV behaves exactly as for a RCV with 
interrogate, and returns "message contains link" error (28). If the 
user wishes to receive the message, the RECEIVE. LINK instruction must 
be invoked. 



14.4.2 RCV. CHAN Receive Message on Channel 

This instruction searches for a message on all channels specified in a 
channel mask, starting with the highest priority channel. If a message 
is found, the instruction transfers the message in a manner identical 
to the RCV instruction. If a message is not found on any specified 
channel, the action is controlled by the "synchronous" parameter, as 
follows: If "synchronous" is selected, the instruction will block the 
user and continue to search the masked channels until a message 
arrives? if false, the instruction terminates. 
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The order in which funnels are checked for messages on a given channel 
is not defined for the user (messages arriving on a funnel are received 
in FIFO order). The channel mask, is specified in the parameter block. 
The instruction otherwise behaves identically to the RCV instruction on 
the receipt of a message and for the "type receive" specification. 



Implementation 



Addressing mode usage 



iO|6,x,y,Z|t,v, 



RCV. CHAN Rx,[Ry] r Rz, [Rt],Rv J 



Opcode 



Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 

= Success 

6 = Message Too Long 

28 = Message Contains Link 

29 = No Messages On Channels 
55 = Transport Hardware Error 



[y] 

[n] 
[n] 
[n] 
[n] 



RCV. CHAN Parameter Block 



Ry]->l 


Channel Mask (16) 


| Type rev (8) | <unused> (8) 




<unused> (16) 


] <unused> (16) 


RCV J 


Link Code (16) 


J Funnel ID (8) | Msg type (8) 


INFO ! 


From Process ID (16) 


] Number of Bytes (16) 


1 1 
1 1 

rz ; 

1 1 


Message 


data block 1 
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[Rt]-> 



Rv 



Message data block 2 



14.4.3 RCV.LINK Receive Message with Link 

This instruction is similiar to RCV in the copy of the message into the 
user's virtual address space. In addition, there is a link table entry 
in the message, which is put into the user's link table according to 
the "preferred link ID" specification. As with RCV, Ry contains the 
virtual address of the parameter block and Rz the length of the message 
block. If [Rv] <> 0, then the message is copied in two parts, with Rt 
specifying the virtual address of the second block and Rv the length. 
Upon completion, status is returned in Rx. 



Implementation 



Addressing mode usage 



i 9 ; o ; s ; 



Opcode 



RCV.LINK Rx,[Ry],RZ,[Rt],Rv 



Rv 2nd message block length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 

= Success 

1 = Funnel Does Not Exist 
6 = Message Too Long 

11 = Link Table Is Full 

12 = Link Already Created 
14 = No Message In Funnel 

30 = Message Does Not Contain Link 

32 = Illegal Preferred Link ID 

55 = Transport Hardware Error 



[y] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
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RCV.LINK Parameter Block 



[Ry]->[ Funnel ID (8) J <unused> (8) J Type rev (8) ! <unused> (8) 


| Preferred Link ID (16) | <unused> (16) 


RCV | Link Code (16) | Funnel ID (8) | Msg type (8) 


INFO ] From Process ID (16) ] Number of Bytes (16) 


i i 

i i 

Rz J Message data block 1 
i i 



[Rt]-> 



Rv 



Message data block 2 



The funnel, receive type and receive control information are the same 
as for RCV. Preferred link ID is the link ID in the receiver's link 
table into which the link entry is placed. If the user has no 
preference, a zero (0) may be specified and the machine will use the 
next free link in the table. In either case, the machine returns the 
actual link ID assigned and places it in the Preferred Link ID field of 
the parameter block. 

If the user executes a RCV.LINK and the machine detects that the 
message does not contain a link, the message is transferred exactly as 
for a RCV, and the "Message Does Not Contain Link" error is returned to 
the user. If status codes 11, 12, or 32 are returned, the message is 
copied into the user's address space but the message is not deleted 
from the funnel and the preferred link is not created. 
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14.4.4 RCV. LINK. ON. CHAN Receive Message with Link on Channel 

This instruction behaves exactly like RCV. LINK, except that a channel 
mask is specified. (See RCV and RCV. CHAN above.) 



Implementation 



Addressing mode usage 



! 9 ! ! 9 ! x | y ! z ! t ] V ! RCV.LINK.ON.CHAN Rx,[Ry],Rz,[Rt],Rv J 



Opcode 



Rv 2nd message block data length 



Rt 2nd message block address 



Rz 1st message block data length 



Ry 1st parameter block address 



Rx = Instruction Specific Return Status 

= Success 

6 = Message Too Long 

11 = Link Table Is Full 

12 = Link Already Created 

29 = No Messages On Channels 

32 = Illegal Preferred Link ID 

55 = Transport Hardware Error 



[y] 

[n] 
[n] 
tn] 
[n] 
[n] 
[n] 
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RCV. LINK. ON. CHAN Parameter Block 



[Ry]-> 



RCV 
CTL 
INFO 



Channel Mask (16) 


Type rev (8) [ <unused> (8) 


Preferred Link ID (16) 


<unused> (16) 


Link Code (16) 


Funnel ID (8) J Msg type (8) 


From Process ID (16) 


Number of Bytes (16) 



Rz 



Message data block 1 



[Rt]-> 



Rv 



Message data block 2 



14.5 FORWARD MESSAGES 

These instructions forward messages from a funnel and send them out on 
a link. Links cannot be forwarded from a message sender, rather the 
EXCH. LINK. FORWARD instruction exchanges the link with one held by the 
intermediate process, and forwards the new link with the original 
message. 



14.5.1 FORWARD. MSG Forward Message 

Take the first message from the funnel specified in the parameter block 
and send it on the specified link. Ry contains the address of the 
parameter block. Upon completion, status is returned in Rx. Messages 
containing links may not be forwarded. 



14 - 25 



MESSAGE SYSTEM INSTRUCTIONS 



Implementation 



Addressing mode usage 



! 8 ! ! A ! x 



Opcode 



FORWARD . MSG Rx , [ Ry ] 



This field must be zero 



Ry parameter block address 



Rx = Instruction Specific Return Status 

= Success 

1 = Funnel Does Not Exist 
14 = No Message In Funnel 
23 = Cannot Forward On Link 
28 = Message Contains Link 

36 = Link 1 Receiving Process Dead 

39 = Link 1 Too Many Attached Buffers 

40 = Link 1 Link Not Defined 

41 = Link 1 Unallocated Page 

42 = Link 1 Unallocatable Page 

43 = Link 1 Exceeds No Of Link Levels 
45 = Link 1 Zero Link ID 

47 = Link 1 Funnel Not Enabled 

55 = Transport Hardware Error 



[y] 

[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
tn] 
[n] 
tn] 
[n] 
[n] 
[n] 



FORWARD. MSG Parameter Block 



[Ry]->! Funnel ID (8) j <unused> (8) j Link ID (8) J <unused> (8) 
! <unused> (32) 



14.5.2 EXCH. LINK. FORWARD Exchange Message Link and Forward Message 

The instruction takes the first message on the funnel specified by 
funnel ID, and forwards it on the link ID specified in the parameter 
block. If the message contains a link, then the link ID contained in 
the message is saved in "preferred link ID", and "link to be sent" is 
substituted instead. Upon completion, status is returned in Rx. Ry 
contains the address of the parameter block. 
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Implementation 



Addressing mode usage 



|8 |o!9ix|y|o; 



EXCH. LINK. FORWARD Rx,[Ry] | 



Opcode 



This field must be zero 



Ry parameter block address 



Rx = Instruction Specific Return Status 

= Success 

1 = Funnel Does Not Exist 

11 = Link Table Is Full 

12 = Link Already Created 
14 = No Message In Funnel 
23 = Cannot Forward On Link 

32 = Illegal Preferred Link ID 

36 = Link 1 Receiving Process Dead 

39 = Link 1 Too Many Attached Buffers 

40 = Link 1 Link Not Defined 

41 = Link 1 Unallocated Page 

42 = Link 1 Unallocatable Page 

43 = Link 1 Exceeds No Of Link Levels 
45 = Link 1 Zero Link ID 

47 = Link 1 Funnel Not Enabled 

51 = Link Cannot Be Sent 

55 = Transport Hardware Error 

140 = Link 2 Link Not Defined 

141 = Link 2 Unallocated Page 

142 = Link 2 Unallocatable Page 

143 = Link 2 Exceeds No Of Link Levels 
145 = Link 2 Zero Link ID 



[y] 

[n] 
[n] 
[n] 
tn] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
tn] 
[n] 
[n] 
[n] 
[n] 
[n] 
[n] 
tn] 
tn] 
tn] 



EXCH. LINK. FORWARD Parameter Block 



[Ry]->! Funnel ID (8) | <unused> (8) 
| Preferred Link ID (16) 



Link ID (16) 
Link to be sent (16) 
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14.6 DELETE MESSAGES 

This instruction disposes of messages. 

14.6.1 DEL.MSG Delete Message from Funnel 

Deletes the first message attached to the funnel specified in Ry. Upon 
completion, status is returned in Rx, and the message buffers holding 
the deleted message are returned to the free list. Messages containing 
links may not be deleted. 



\ Implementation | 



Addressing mode usage J 
DEL.MSG Rx,Ry ! 



| 8 | J 4 ! X J y J 



: 



Opcode 



This field must be zero 



Ry Funnel ID 



Rx = Instruction Specific Return Status 

= Success 

1 = Funnel Does Not Exist 
14 = No Message In Funnel 
28 = Message Contains Link 

55 = Transport Hardware Error 



[y] 

[n] 
[n] 
[n] 
[y] 



14.7 ENABLE AND DISABLE FUNNEL 

These instructions toggle the enabled funnels bit in the Enabled 
Funnels Map of the Process Control Block. This has the effect of 
marking the associated funnel as enabled or disabled. The Enabled 
Funnels Map contains an enabled funnels bit for each of a process' 256 
funnels. Chapter 13, "Inter-Process Communications", covers this data 
structure in detail. 
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14.7.1 ENABLE. FUN Enable Funnel 

The funnel specified in Ry is marked enabled in the enabled funnel map. 
Any subsequent messages directed to the funnel will be delivered. 
Status is returned in Ex. 



Implementation 



Addressing mode usage 
ENABLE. FUN Rx,Ry 



8 ! ! 7 



X | y | 1 



Opcode 



This field must be zero 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success [y] 

1 = Funnel Does Not Exist [n] 
21 = Specified Funnel Already Enabled [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



14.7.2 DISABLE. FUN Disable Funnel 

The funnel specified in Ry is marked disabled in the enabled funnels 
map. All messages currently attached to the funnel remain attached, 
but subsequent messages directed to the funnel will not be attached and 
bad (non-zero) status will be returned to the sender of the message. 
Upon completion of the DISABLE. FUN instruction, status is returned in 
Rx. 



14 - 29 



MESSAGE SYSTEM INSTRUCTIONS 



Implementation 



Addressing mode usage 
DISABLE. FUN Rx,Ry 



! 5 | x J y 



Opcode 



This field must be zero 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success [y] 

1 = Funnel Does Not Exist [n] 

17 = Illegal To Disable Funnel ID [n] 

18 = Specified Funnel Already Disabled [n] 
50 = Access Unallocated Page Of Funnel Table [n] 



14.8 INTERRUPT AND LOCAL PRIORITY 



If a channel is enabled for interrupts, any message arriving on a 
funnel attached to the channel will generate an interrupt. Assuming 
that no higher priority interrupts are extant, the instruction stream 
of the process will be interrupted when the firmware loads the Program 
Counter with the interrupt vector, that is, the address of the trap 
handler. The trap handling procedure interprets the parameters passed 
by the message that generated the interrupt. These mechanisms are 
discussed in Chapter 2, "Architecture". 



These instructions allow the process to control local 
interrupt channel masks, and the interrupt vectors. 



priority, the 



14.8.1 DISABLE. CHAN. INT Disable Interrupts on Channel 

The channel (s) specified in the channel mask are marked to disable 
interrupts by setting the associated bit(s) in Ry. Thereafter, 
messages delivered to funnels attached to such channels will not cause 
an interrupt. Upon completion, the old channel mask is returned in Ry 
and status is returned in Rx. If the return status is non-zero, Ry is 
unchanged. Interrupts may be disabled on any channel except channel 0. 
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Channel mask in Ry, right justified 
/ / 



Channel -> 



i 00 | 01 | 02 



-/ /- 



... 12 | 13 

... 60 61 



14 I 15 ! 



Bit position 47 48 49 . . . 



62 63 



Implementation 



! Addressing mode usage \ 



! 8 ! ' 6 ! x ! 



Opcode 



y ! o ! 



DISABLE. CHAN. INT 



Rx,Ry 



This field must be zero 



Ry Channel mask 



Rx = Instruction Specific Return Status 

= Success 
15 = Illegal To Disable Interrupts 



[y] ! 
tn] J 



The channel mask is represented in the machine with bits set for 
enabled channels, and bits cleared for disabled channels. The value 
returned in Ry for the old channel mask will be displayed accordingly. 



14.8.2 EN ABLE. CHAN. INT Enable Interrupts on Channel 

The channel (s) specified in the channel mask are marked to enable 
interrupts by setting the associated bit(s) in Ry. Existing messages 
on the funnels for the enabled channel will cause interrupts as well as 
the delivery of subsequent messages. On completion, the old channel 
mask is returned in Ry and status is returned in Rx. 
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Implementation 



| Addressing mode usage ] 



8!o;8|x;y[o! 



ENABLE. CHAN. INT 



Rx,Ry 



Opcode 



This field must be zero 



Ry Channel mask 



Rx = Instruction Specific Return Status 



- Success 



[y] 



The channel mask is represented in the machine with bits set for 
enabled channels, and bits cleared for disabled channels. The value 
returned in Ry for the old channel mask will be displayed accordingly. 

14.8.3 SET. FUN. I NT. VECTOR Set Funnel Interrupt Vector 

The interrupt vector for the funnel specified in Ry is changed to the 
value specified in Rz. Upon completion, the old interrupt vector is 
returned in Rz, and status is returned in Rx. If a non-zero status is 
returned in Rx, then Rz is unchanged. The interrupt vector for funnel 
•1 cannot be modified with this instruction. 

All vectors point to the system interrupt handlers at process start-up. 
A value in Rz of zero is illegal, as it will cause an access violation 
to page zero if an interrupt should occur that uses this vector. 
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Implementation 



Addressing mode usage 



: s : o 



C | x ! y ! z ; 



SET. FUN. INT. VECTOR Rx,Ry,Rz 



Opcode 



Rz Interrupt vector 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success ty] 

1 = Funnel Does Not Exist [n] 
7 = Illeg. To Modify Int. Vector On This Funnel[n] 

50 = Access Unallocated Page Of Funnel Table [n] 



14.8.4 SET. LOCAL. PRI Set Local Priority 

The local priority of the caller is modified to either the priority in 
Ry or the priority of the highest active channel, whichever is higher. 
An active channel is any channel having a funnel that contains a 
message. On completion, the old local priority is returned in Ry. No 
status code is returned with this instruction. 



Implementation 



Addressing mode usage 



! 9 ! ! D 



SET. LOCAL. PRI 



Ry 



Ry specifies new local priority and 
returns old local priority 



Opcode 
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14.9 PROCESS INQUIRY 

These instructions read the link and funnel table entries. If the 
input parameter is zero, the associated link or funnel table header is 
returned . 



14.9.1 READ.FTE Read Funnel Table Entry 

The funnel table entry for the funnel specified in Ry is returned in 
registers Rz and Rt. If zero is specified, then the funnel table 
header is returned. Rz holds the first word of the funnel table entry, 
and Rt holds the second word of the funnel table entry. The status is 
returned in Rx. Upon completion, if [Rx] is not equal to zero, then 
the contents of Rz and Rt have no meaning. 



Implementation 



Addressing mode usage [ 
READ.FTE Rx,Ry,Rz,Rt J 



| 9 J [ 2 



x ! y I 



z I t ! o ; 



Opcode 



This field must be zero 



_Rt 2nd word of funnel table entry 



_Rz 1st word of funnel table entry 



Ry Funnel ID 



Rx = Instruction Specific Return Status 



= Success [y] 

50 = Access Unallocated Page Of Funnel Table [n] 
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14.9.2 READ.LTE Read Link Table Entry 

The link table entry for the link specified in Ry is returned in 
registers Rz and Rt. If zero is specified, then the link table header 
is returned. Rz holds the first word of the link table entry, and Rt 
holds the second word of the link table entry. The status is returned 
in Rx. Upon completion, if [Rx] is not equal to zero, then the 
contents of Rz and Rt have no meaning. 



Implementation 



Addressing mode usage 
READ.LTE Rx,Ry,Rz,Rt 



I g i 



x ; y ; z | t ; o ; 



Opcode 



This field must be zero 



Rt 2nd word of link table entry 



Rz 1st word of link table entry 



Ry Link ID 



Rx = Instruction Specific Return Status 

= Success 

41 = Link 1 Unallocated Page 

42 = Link 1 Unallocatable Page 

43 = Link 1 Exceeds No Of Link Levels 



[y] 

[n] 
[n] 
[n] 
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15 GENERAL INSTRUCTIONS 

This chapter covers the miscellaneous instructions: 

MEMORY. MAN Memory Management 

MODIFY. PME Modify Page Map Entry 

READ.PME Read Page Map Entry 

NOP No Operation 

READ. CPU. TIMER Read CPU Timer 

RE AD. REAL. TIMER Read Real Time Clock 

READ. STAT Read Process Status Word 

WRITE. STAT Write Process Status Word 

READ.MACH.ID 

15.1 MEMORY. MAN MEMORY MANAGEMENT 

This instruction sends a message to the Memory Manager Process to 
request an operation on a page or group of pages. The request may be 
either synchronous or asynchronous. If synchronous, then the process 
executing this instruction will be stopped until the Memory Manager 
explicitly restarts it. Rx contains the operation code to be performed 
by the memory manager, Ry contains the starting address of the virtual 
page(s), and Rz contains the number of bytes in the page(s). 
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Implementation 



Addressing mode usage 
MEMORY . MAN Rx , [ Ry ] , Rz 



i 



Opcode 



Rz number of bytes 



Ry starting address of page(s) 



Rx = Memory manager operation code 

Asynchronous TOUCH 

1 Synchronous TOUCH 

2 Asynchronous FORCE 

3 Synchronous FORCE 

4 Asynchronous CLEANSE 

5 Synchronous CLEANSE 



TOUCH is an asynchronous hint to start a pre-fetch on a page or a group 
of pages. 

FORCE is a request to write a page or a group of pages to disk. The 
reference bit is not modified. If the page(s) are not dirty, then they 
are not written. 

CLEANSE is a request to reset a page or group of pages to "virgin". 
This resets the page map entry (PME) for every virtual page having an 
actual page of disk space. When the page is subsequently referenced, 
the Memory Manager will not fault the page in off of disk, but instead 
will allocate a zeroed page in physical main memory. The copy on disk 
will not be initialized to zero as is normally the case when a page is 
allocated. This is typically used to clean pages that have not been 
referenced and do not need to be written to disk. 



15.2 MODIFY. PME MODIFY PAGE MAP ENTRY 

Rx contains the clear bit mask and Ry contains the set bit mask to 
modify the PME bits. Rz contains the address of the page belonging to 
the PME. In the bit masks, a bit having the value one indicates that 
the appropriate operation is to be performed on the corresponding bit 
in the PME. A bit having the value zero indicates that the 
corresponding bit in the PME is not to be modified. 

The instruction operates as follows: [Rx] and [Ry] are first ANDed 
with internally maintained masks to restrict the PME bits that the user 
may modify. The clear mask is applied first. To clear bits, the 
verified [Rx] is complemented and ANDed with the PME. This result is 
then ORed with the verified [Ry]. The PME is then rewritten. The only 
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bits which may be modified are the three trace bits and the reference 
bit. The instruction operates correctly on shared pages. 



PME bits 



type 



maintenanceBit 
readTraceBit 
writeTraceBit 
executeTraceBit 



boolean 
boolean 
boolean 
boolean 



! mask bit ! 



60 
61 
62 
63 



Implementation 



Addressing mode usage 



7 ! ! 1 



x ! y I z ! 



MODIFY. PME 



Rx,Ry, [Rz] 



Opcode 



Rz page address 



Ry set bit mask 



Rx clear bit mask 



15.3 NOP NO OPERATION 

The NOP instruction has no action other than to cause the PC to be 
incremented to the next instruction. 



: 5 ; o : 



A___A 



Opcode 



Instruction Specific Exceptions: none 
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15.4 READ. CPU. TIMER 

Load the specified register with the 64-bit Process CPU Timer. 



[ Implementation 



| Addressing mode usage [ 



! 4 J X J 



Opcode 



READ. CPU. TIMER 



RX 



Rx specifies register to return value 



Instruction Specific Exceptions: none 

Each process has a 64-bit CPU Timer which is initialized at process 
start-up to zero. The timer is incremented by one every 25 nanoseconds 
when the process is executing. 



15.5 READ.MACH.ID 

Load the specified register with the 64-bit CPU identification code. 
This code is unique for each CPU and is assigned when manufactured. 
The contents of the identification code are currently undefined. 



[ Implementation 



Addressing mode usage 



I 6 



: o : 



3 ; x ; 



Opcode 



READ.MACH.ID 



Rx 



Rx specifies register to return value 



Instruction Specific Exceptions: none 
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15.6 READ.PME READ PAGE MAP ENTRY 

The page map entry for the page containing the byte address in Ry is 
returned in Rz. The PME level is returned in Rt. A page map entry is 
always returned, regardless of whether or not the address in Rz is 
allocatable or not. The status is returned in Rx. If the return value 
of [Rx] is non-zero, then Rz is not modified. 



Implementation 



Addressing mode usage 



i o ; 



! x ; y ; z ; t ; 



READ.PME 



Rx,[Ry] ,Rz,Rt 



Opcode 



Rt level of returned PME 



Rz returned PME 



Ry page address 



Rx = Instruction specific Return Status 



Success 
| 32 Illegal page address 



15.7 READ. REAL. TIMER 

Load the specified register with the 64-bit Absolute Timer. 



Implementation , 



i Addressing mode usage 
! READ. REAL. TIMER Rx 



! 6 J J 5 | X 



Opcode 



Rx specifies register to return value 



The Service Processor contains a battery powered clock which measures 
time and date. At cold load of the system, the time and date are 
converted to a value which represents the absolute number of 25 
nanosecond ticks which have occurred since a base time and date. This 
value is placed into the Real Time Clock at CPU initialization. The 
Real Time Clock in incremented by 1 every 25 nanoseconds. Since the 
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clock is 64 bits wide, the clock can time an interval of over 7,200 
years (not counting the sign bit) . 

The base time is March 1, 1600. 



15.8 READ. STAT READ PROCESS STATUS WORD 

Load the specified register with the 64-bit Process Status Word. 



Implementation] [ Addressing mode usage ] 

6 ! ! 6 ! X ! ! READ. STAT Rx ! 



i 



1 ! Rx has the returned value for the PSW 



i 
Opcode 



Instruction Specific Exceptions: none 

15.9 WRITE. STAT WRITE PROCESS STATUS WORD 

Copy the specified register into the 64-bit Process Status Word. 



] Implementation | | Addressing mode usage ] 

! 6 I | 7 J x ; ; WRITE. STAT Rx \ 



A A A 



, Rx is source for new PSW 

Opcode 



Instruction Specific Exceptions: none 
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APPENDIX A: ALPHABETICAL LIST OF OPCODES 



ADD 

ADD I 

ADDUC 

AND 

ASCI I. ADD 

ASCII.ADDC 

ASCI I. SUB 

ASCII.SUBC 

ATT. FUN. TO. CHAN 

BR.ABS 

BR. BACKWARD 

BR.B.<Cd>.SH.REL 

BR.<Cd>.ABS 

BR.<Cd>.REL 

BREAKPOINT 

BR.F.<cd>.SH.REL 

BR. FORWARD 

BR. REG 

BR.REL 

BXIT 

CALL 

CALL. REG 

CLEAR. BIT 

CMP 

CMPB.BR 

CMPB. BR. CONST 

CMP. BR 

CMPB. TEST 

CMPU 

CMPU.BR 

COPYB 

COPYB. CONST 

COPY. LINK 

CREATE. FUN 

CREATE. LINK 

CVT.AI 

CVT.DE 

CVT.DI 

CVT.DS 

CVT.ED 

CVT.EI 

CVT.ES 

CVT.IA 

CVT.ID 

CVT.IE 

CVT.IS 

CVT.SD 

CVT.SE 

CVT.SI 

DEL. FUN 

DEL. LINK 



Integer Addition 6.2 

Integer Addition with Immediate Operand 6.2 

Unsigned Integer Addition Generate Carry 6.2 

Logical AND 9.2 

ASCII Addition 8.1 

ASCII Addition Generate Carry 8.1 

ASCII Subtract 8.2 

ASCII Subtract Generate Carry 8.2 

Attach Funnel to Channel 14.6 

Branch Absolute 12. 3 

Branch Backward Short 12.3 

Branch Backward 12.5 

Branch Register Conditional 12.4 

Branch Register Conditional 12 . 4 

Breakpoint 12 . 10 

Branch Forward 12 . 5 

Branch Forward Short Relative 12 . 3 

Branch through Register 12. 7 

Branch Relative 12. 3 

Exit from Break 12 . 11 

Procedure Call Through Stack 12.7 

Procedure Call Through Register 12.8 

Clear Bit 9.3 

Compare 10.5 

Compare Byte Strings and Branch 10.9 

Compare Byte String & Constant, Branch 10.10 

Compare Signed Integers and Branch PC 10.4 

Compare Byte Strings and Test 10 . 11 

Compare Unsigned Integers 10.5 

Compare Unsigned Integers and Branch PC 10.4 

Copy Byte String 5.8 

Copy Constant Byte String 5.9 

Copy Link 14 . 12 

Create Funnel 14.5 

Create Link to Funnel 14.4 

Convert from ASCII to Integer 11.3 

Convert from Double to Extended 11.4 

Convert from Double to Integer 11.4 

Convert from Double to Single 11.4 

Convert from Extended to Double 11 . 5 

Convert from Extended to Integer .11.5 

Convert from Extended to Single 11 . 5 

Convert from Integer to ASCII 11.3 

convert from Integer to Double 11 . 6 

convert from Integer to Extended 11.6 

Convert from Integer to Single 11 . 6 

Convert from Single to Double 11 . 7 

Convert from Single to Extended 11 . 7 

Convert from Single to Integer 11 . 7 

Delete Funnel 14.8 

Delete Link 14 . 7 
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DEL.MSG 

DISABLE. CHAN. INT 
DISABLE. FUN 
DIV 
DIVR 

ENABLE. CHAN. INT 

ENABLE. FUN 

EXCEPTION 

EXCH 

EXCH.AND 

EXCH . LINK . FORWARD 

EXCH. OR 

EXIT 

EXTRACT 

EXTRACTZ 

FADD 

FCMP 

FCMP.BR 

FCMPX 

FCMPX.BR 

FDIV 

FDIVR 

FIND. FIRST 

FINP 

FMUL 

FORWARD. MSG 

FREM 

FSQR 

FSUB 

FSUBR 

INSERT 

IXIT 

LD 

LDZ 

MEMORY. MAN 

MODIFY.PME 

MUL 

MUL.128 

MULU.128 

NEG 

NOP 

NOT 

OR 

PASS. LINK 

RCV 

RCV.CHAN 

RCV. LINK 

RCV. LINK. ON. CHAN 

READ. CPU. TIMER 

READ.FTE 

READ.LTE 

READ.MACH.ID 

READ.PME 

READ. REAL. TIMER 



Delete Message from Funnel 14.25 

Disable Interrupts on Channel 14. 26 

Disable Funnel 14.24 

Integer Division 6.3 

Reverse Integer Division 6.3 

Enable Interrupts on Channel 14.27 

Enable Funnel 14.23 

Exception 12 . 10 

Exchange Register and Memory 5.7 

Exchange AND 5.7 

Exchange Message Link, Forward Message 14.22 

Exchange OR 5.7 

Exit 12 .9 

Extract Bit Field, Sign Extended 5.5 

Extract Bit Field, Zero Extended 5.5 

Floating Point Addition 7.2 

Floating Point Compare 10.8 

Floating Point Compare , Branch 10 . 6 

Floating Point Compare , Unordered 10.8 

Floating Point Compare Branch, Unordered 10.6 

Floating Point Division 7.4 

Floating Point Division Reversed 7.4 

Find First Logical One 9.4 

Floating Point Integer Part 11 . 8 

Floating Point Multiply 7.6 

Forward Message 14.21 

Floating Point Remainder 7.8 

Floating Point Square Root 7.9 

Floating Point Subtraction 7.10 

Floating Point Subtraction Reversed 7.10 

Insert Bit Field Operation 5.6 

Exit from Interrupt 12 . 11 

Load Register Sign Extended 5.2 

Load Register Zero Extended 5.2 

Memory Management 15.2 

Modify Page Map Entry 15.3 

Integer Multiply 6.4 

128-Bit Integer Multiply 6.4 

128-Bit Unsigned Integer Multiply 6.4 

Integer Negate Operations 6.5 

No Operation 15.4 

Logical NOT 9.2 

Logical OR 9.2 

Pass Link 14.14 

Receive Message 14.15 

Receive Message on Channel 14. 17 

Receive Message with Link 14.18 

Receive Message with Link on_Channel 14. 20 

Read CPU Timer 15.5 

Read Funnel Table Entry 14. 30 

Read Link Table Entry 14 . 31 

Read Machine ID 15.6 

Read Page Map Entry 15 . 7 

Read Real Time Clock 15.8 
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READ. STAT 

REM 

REMR 

ROL 

ROR 

SEND 

SEND. SMALL. MSG 

SEND . TO . HARDWARE 

SET. BIT 

SET. INT. VECTOR 

SET. LOCAL. PRI 

SLA 

SLL 

SLL1 

SLL2 

SLL3 

SLR 

SRA 

ST 

STI 

STIN 

STV 

SUB 

SUBI 

SUBR 

SUBUC 

SUBUCR 

TOGGLE. BIT 

WRITE. STAT 

XOR 



Read Process Status Word 15.9 

Remainder of Integer Divide 6.6 

Remainder of Reverse Integer Divide 6.6 

Logical Rotate Left 9.4 

Logical Rotate Right 9.4 

Send Message 14.9 

Send Small Message 14 . 10 

Send Message to Hardware 14.11 

Set Bit 9.3 

Set Funnel Interrupt Vector 14 . 28 

Set Local Priority 14 . 29 

Shift Left Arithmetic 6.10 

Shift Left Logical 9.5 

Shift Left Logical by 1 9.6 

Shift Left Logical by 2 9.6 

Shift Left Logical by 3 9.6 

Shift Right Logical 9.5 

Shift Right Arithmetic 6.10 

Store Register 5.3 

Store Immediate 5.4 

Store Immediate Negated 5.4 

Store Register with Overflow Check 5.3 

Integer Subtract 6.7 

Integer Subtraction with Immediate Operand 6.9 

Reverse Integer Subtract 6.7 

Unsigned Integer Subtract Gen Carry 6.8 

Reverse Unsigned Integer Subtract Gen Carry 6.8 

Toggle Bit 9.3 

Write Process Status Word 15.10 

Logical. Exclusive OR 9.2 
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APPENDIX B: DATA TYPES 



i i 

1 i 



ii ii 

i i • • • i i 



n-l 



1 ~ i 



31 



57 63 



49 63 



1 b 1 


<extend bits> [ 


i 
i 





33 


63 


! 



8-bit Character 



Character String 
1 <= n <= 2**32 



s | 8-bit Integer in 

memory 



7 

and 

s| <extend bits> | | in register 



| s J 16-bit Integer in 
memory 

15 

and 

is| <extend bits> J | in register 



]s ! 32-bit Integer in 



memory 
and 

in register 



64-bit Integer in 
memory and 
register 



63 



DATA TYPES 



Jseee f. 




31 



Single Floating 
in memory 



Jo... 





seee f . 



32 



63 



and 
in register 



i seee eef... 
A 



63 



Double Floating 
in memory 
and register 



16 
| seee eeee \ . . 



[If... 
64 A 



63 



127 



Double Extended 
Floating in 
memory 
and 
register 



s 
e 
f 
I 
h 

A 



sign bit 

exponent bit(s) 

fraction (significand) bit 

Integer bit of significand if no hidden bit 

apparent position of hidden bit 

position of binary point 



Numeric string in register 



! x ; d ! x | d ; x ! d ! x 



D , x ; D ; x ; d ; x 



x ! D 



d ; x ; d ; 



where 

x = hex3 or [= if all bits to left or right 
D = hexO through hex9 



= 0] 
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APPENDIX C: GENERALIZED ADDRESSING INSTRUCTION FORMATS 



1 reg, reg 



J |OPli w I x | 



op Rx,Rw 



1 reg, reg 



I 1 jOPli w | x ; 



op Rx , Rw 



Mode 2: Reserved for future use 



2 reg, reg 



I 3 JOP1JOP2J x J y J 



op Rx,Ry,Rz 



1 reg, absolute 



! 4 !opi!op2! x j 16 bit vir abs! 



| WJT J. , Wt i. | SL | 



op Rx,e{l6) 



2 reg, immediate 



5 |0Pl!0P2| x J y J 12-bit imm 



op Rx,Ry,=e{l2} 



2 reg, long absolute 



■ ■ • i 



; 6 iopi|op2| x ; y ; 



<32-bit address> 



2 reg, long immediate 



op Rx,Ry,e{32} 



| 7 |0Pl]0P2| x | y | - ] 



<32-bit immediate> 



GENERALIZED ADDRESSING INSTRUCTION FORMATS 

Stack pointer relative 

! 8 JoPl| n | x | op Rx,[ ]e(6} 



where e = 4n, <= n <= 15 
Stack pointer relative 
! 9 JoPli n 1 x [ op Rx,[ ]e{6} 

where e = 4n, <= n <= 15 
Reg, base + zero displacement 

I a jopi| w ; x ; op rx,[rw] 



2 reg, base + zero displacement 

! B |0P1|0P2| x ! y J z J op Rx,Ry,[Rz] 



1 reg, base + index + zero displacement 



! C |0P1|0P2| x | y [ z J op Rx,[Ry][Rz] 



1 reg, base + 12-bit displacement 

1 D |0Pl|0P2! x I y ; 12-bit disp; op Rx,[RyJ,e{l2} 



1 reg, base + index + 32-bit displacement 

| E j0Pl|0P2j x J y I z J <32-bit displacement 



op Rx,[Ry][Rz]e{32} 



GENERALIZED ADDRESSING INSTRUCTION FORMATS 

2 reg, base + 32-bit displacement 

| F |0Pl|0P2j x J y J z | <32-bit displacement \ 

op Rx,Ry r [Rz]e{32} 
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APPENDIX D: NON-GENERALIZED ADDRESSING INSTRUCTION FORMATS 



EXCEPTION 



:o;o!o;x!-: y ; 



FREM, MUL.128, MULU.128 



; o ! o |op2| x ! y ! z ; 



BREAKPOINT 



1 1 ' ' 



BR. FORWARD 



2 J ;<displ>| 



(PC + UNSIGNED <displ>) 



EXIT, IXIT, BXIT 



; 3 ; o ;op2i - ; i ; 



(ADD UNSIGNED I TO GPR 15) 



SET. BIT, CLEAR. BIT, TOGGLE. BIT 



3 I |OP2| X i I 



(BIT I IN GPR X) 



BR . F . <Cond> . SH . REL 



[ 3 J !OP2i x ;<displ>j (PC + UNSIGNED <displ>, IF TRUE) 



NON-GENERALIZED ADDRESSING INSTRUCTION FORMATS 



NOP 



i 



5 ; o ; 

BR. REG, READ. , WRITE. STAT, CASE 

| 6 J |OP2| X ; 
EXCH, EXCH.AND, EXCH.OR, CVT.AI, CVT.IA 

; 7 ; o |op2! x ; - ; z ; 

MEMORY. MAN, MODIFY. PME, ASCII. , COPYB, COPYB. CONST, CMPB.TEST 



I 7 ; o |op2; x ; y ; z ; 



Message System 1 



i 8 ; o ;op2[ x ; y ; z ; 



Message System 2 and SET . LOCAL . PRI 



I 9 ; o ;op2| x ; y ; z ; t ; v ; 



ASCI I. SUB 



JsIojEixiyjzit;-; 



BR. BACKWARD 



! A j |<displ>! (PC - UNSIGNED <displ» 



NON-GENERALIZED ADDRESSING INSTRUCTION FORMATS 

BR . B . <COnd> . SH . REL 

I B i iOP2j X [<displ>| 
CMPB.BR, CMPB. BR. CONST 

| D | |OP2l x | y ! z |ccd|<12-bit ds> 



(PC - UNSIGNED <displ>, IF TRUE) 



INSERT 



I D ! I 5 |x ! y ! z HI start \\\ len \ 
EXTRACT, EXTRACTZ 

| D | 1 0P2 [ x | - | z | | | start J J 64-len J 
FCMP.BR.80, FCMPX.BR.80, FCMP.80, FCMPX.80 



| D | | OP2 | x | y | z | appendage | 



CALL, BR.ABS, BR. REL 

I E I |OP2', - ! - | - | <32-bit displ> ; 
CALL. REG, BR.<cond>.ABS, BR.<cond>.REL 

J E | |OP2; x ! - I - ! <32-bit displ> | 
CVT.IE, CVT.EI, CVT.ES, FXXX.80 

! F 1 [0P2| x J y | z | 
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APPENDIX E: ELXSI MACHINE INSTRUCTION DESCRIPTORS 

M The effective address of an operand. 

[M] The contents of memory location M. 

Rspec Register specifiers reside in the fields tabled below for 
appropriate instructions. 



| nibble | 2 | 3 | 4 | 5 | 6 | 7 
| register [wjxjyjzltjv 



Rn The contents of register Rn, where n = to 15. 

[Rn] The contents of register Rn points to a memory location. 

<- The replace descriptor (e.g., [M] <- Rx means "the contents of 
the memory location pointed at by M is replaced by the 
contents of Rx"). 

=Rx The nibble in the instruction which normally specifies 
register Rx is interpreted as an immediate operand. 

RR Register to register instruction. 

RM Register to memory or memory to register instruction. 

x In Short Op form, this represents nibble 2 as register Rw. 
Example: m3x, where m is the addressing mode. 

m Refers to the 1st nibble in the instruction. (nibble 0) , For 
generalized and short opcode instructions, this represents the 
addressing mode. 

OP0 Refers to the 1st nibble in the instruction (nibble 0) , which 
for non-generalized instructions is the first opcode 
specifier. 

0P1 Refers to the 2nd nibble in the instruction (nibble 1) , which 
is OPcode specifier 1. 

0P2 Refers to the 3rd nibble in the instruction (nibble 2) , which 
is OPcode specifier 2. 

e Represents an expression which can be evaluated by the 
assembler and results in an integer value. If an "=" preceeds 
the "e", then the expression is used as an immediate operand. 
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{} These delimiters, which may follow an expression, enclose a 
value that indicates the bit-size of the field which will hold 
the integer result of the expression. For example, =o(l2) 
would force the usage of the 12-bit immediate mode, while 
=0(32} would force the 32-bit immediate mode. If this 
specification is not present, the assembler will use either 
the 12- or 32-bit mode, depending on the magnitude of the 
value of the expression. 

[] When enclosing a register specification, indicates that the 
contents of the register are to be used as the address of the 
operand, rather than as the operand itself. If used without a 
register specification, the stack pointer (RF) is assumed. 
This is the manner in which modes 8 and 9 are forced. 

, The comma is used to separate operands. Values appearing next 
to each other in a single operand, if allowed, are summed 
together to generate the effective address of the operand. 
Thus, "[R3]1500" would be interpreted as "add 1500 to the 
contents of register 3 and use this as the effective address 
of the operand". "[RA][R6]10" would be interpreted as "add 10 
to the sum of the contents of register 10 plus the contents of 
register 6, and use this as the effective address of the 
operand". 

[op]:<s:l> The effective operand is the bit string in the operand 
starting at st and of length len. 
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Index 

absolute timer, 15-5 
ADD, 

definition, 6-4 

reference, 6-1 
ADDI, definition, 6-4 
address calculations, 4-5 

overflow, 4-5 
address, data, 3-1 
address evaluation, 4-5 
address mode, 4-3 

usage , 4-5 
address space, 4-5 
addressing mode interpretation, 4-2 
addressing modes, discussion, 4-1 
ADDUC, definition, 6-4 
AND, definition, 9-1 
appendage , 10-1 
architecture, 2-1 

arithmetic, multiple precision, 6-2 
Arithmetic Shift instructions, 6-12 
array indexing, 9-4 
ASCII Arithmetic Instructions, 8-1 
ASCI I. ADD, definition, 8-4 
ASCII. ADDC, definition, 8-4 
ASCII. SUB, definition, 8-5 
ASCII. SUBC, definition, 8-5 
assembler notation, E-l 
assembler register definitions, 4-4 
ATT. FUN. TO. CHAN, description, 14-6 

battery powered clock, 15-5 

binary point, 3-1 

BlQ-pair, 13-6 

bit numbering, 3-1 

boolean operations, 9-1 

BR.ABS, definition, 12-1 

BR. BACKWARD, definition, 12-2 

BR.B.<cond>.SH.REL, definition, 12-3 

BR.<cond>.ABS, definition, 12-3 

BR.<cond>.REL, definition, 12-3 

BR.F.<cond>.SH.REL, definition, 12-4 

BR. FORWARD, definition, 12-2 

BR. REG, definition, 12-5 

BR.REL, definition, 11-2 

BREAKPOINT, 

definition, 12-8 

entry environment, 2-8 
breakpoints, discussion, 2-8 
BXIT, 

definition, 12-10 

single stepping enabled, entry environment, 2-8 

usage, 2-10 
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cache , 5-8 
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channel ID, 13-22 
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channel priority, 13-25 
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CLEAR. BIT, definition, 9-2 
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CMPU, definition, 10-6 
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DIV, definition, 6-5 

DIVR, definition, 6-5 
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ENABLE. CHAN. INT, definition, 14-31 
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FP Invalid Operation, 3-10 
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EXIT, definition, 12-7 
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Extended Double, Floating Point, 3-5 
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usage, 6-12 
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FDIV, definition, 7-4 
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Index - 



INDEX 
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Flow of Control instructions, 12-1 
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FMUL result matrix, 7-6 
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FP Invalid Operation exception, 3-10 
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immediate operand, assembler, E-l 
inexact result exception, 3-10 
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link, data structure, 13-17 
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link rights, 13-17 
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Logical instructions, 9-1 

logical operations, 9-1 
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NEG, definition, 6-8 
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NOP, definition, 15-3 
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NOT, definition, 9-1 
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security, 13-2 
Process Status Word, 2-1 
process substitution, 13-1 
PSW, 15-6 

reference, 15-6 
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ROL, definition, 9-3 

ROR, definition, 9-3 
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